Minetest logo

IRC log for #minetest-dev, 2013-12-01

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:01 iqualfragile sapier: whover cares about mingw: fix it
00:03 sapier I'm gonna stop supporting any windows thingy if I'm the only one who's required to support all different windows build variants
00:11 ShadowNinja sapier: Um, don't remove whitespace from the whole repo, just from Jthread.
00:12 sapier I had to touch all those files for jthread cleanup ... and every file I change is fixed automaticaly ... it's a all or nothing decision
00:12 PilzAdam sapier, alternatively you rebase every single pull request
00:12 sapier PilzAdam I guess I already do that the last days
00:13 sapier that damn windows build works on exactly one machine
00:14 sapier I interpret this as "not fixing trailing line ends"
00:15 PilzAdam we can fix this once and for all when our pull request list is shorter
00:16 sapier that wont ever happen PA
00:16 sapier but I don't care about I'll find out how to revert keplers default behaviour to old juno style
00:25 hmmmm I do agree that there needs to be a point when we remove all trailing whitespace
00:26 hmmmm my IDE did that for a while and it kept making a mess of my commits
00:26 hmmmm until I figured out how to disable it
00:26 hmmmm and now it's annoying to do "git diff" and have trailing whitespace highlighted in red
00:26 hmmmm so I have to go back and manually fix that
00:26 iqualfragile hmmmm: isnt there some way to ignore whitespace changes?
00:26 hmmmm shrug
00:27 sapier I don't want to waste energy on whitespace discussions while I could use it for more usefull things
00:43 ShadowNinja So, at what point will we trim the whitespace? 30 PRs? 10 PRs?
00:43 sapier never
00:51 hmmmm agh fuckfuckfifcufkcufck
00:51 hmmmm I just realized i need to keep an intermediate schematic buffer to apply the trim to
00:52 hmmmm so listen to how fast this is:
00:52 sapier https://github.com/minetest/minetest/pull/1029 what about this variant only remove trailing whitespaces from non empty lines
00:52 hmmmm 1. apply rotation
00:52 hmmmm 2. blit to intermediate buffer with probabilities
00:53 hmmmm 3. trim schematic
00:53 hmmmm 4. blit to the vmanip
00:53 hmmmm 5. blit back to the map
00:53 hmmmm that's technically 3 buffers
00:53 sapier guess it's the only way to do
00:54 hmmmm and then it does this for every single tree
00:54 hmmmm i need to do some profiling and see how horrible this is
00:55 sapier why don't you cache em? is memory usage that huge?
00:55 hmmmm well this is generalized
00:56 hmmmm if I were to cache something, it'd have to be one for every single possibility of the schematic
00:58 hmmmm http://paste.ubuntu.com/6502012/  this is what I'm doing
00:58 ShadowNinja local schemid = minetest.prepere_chematic("path", options) minetest.spawn_schematic(schemid)
00:59 ShadowNinja goto == bad.
01:00 hmmmm lol
01:01 hmmmm hmmm
01:01 hmmmm am I overgeneralizing this?
01:02 hmmmm realistically the only direction I need is -y, +y would only be for ceiling placement and I don't even have ceiling placement for schematics added
01:08 hmmmm this doesn't even fit the purpose of what I'm doing very well
01:08 hmmmm take for example a jungle tree which has a base with a specific shape
01:09 hmmmm if it generates shorter, the length would vary in the middle of the trunk, not along the edges
01:09 hmmmm somebody just tell me if generically, programatically doing this is possible or not
01:11 PilzAdam maybe propabilities per horizontal layer?
01:11 Sokomine joined #minetest-dev
01:12 hmmmm how would you possibly 1). encode that with the current schematic format but more importantly 2). specify which slice tangential to the y axis has a probability or not
01:15 hmmmm i suppose #1 is impossible, and #2 can only be done through the player specifying the y offset through the console or something
01:16 sapier the win32 sleep fix doesn't work it needs to be used for mingw too not only for msvc
02:29 ecube joined #minetest-dev
02:34 Miner_48er joined #minetest-dev
02:38 salamanderrake joined #minetest-dev
02:48 VanessaE joined #minetest-dev
02:53 hmmmm god
02:53 hmmmm dammit
02:53 hmmmm why do i keep making retarded decisions on which order to put lua api parameters in
02:56 VanessaE don't we all make bad decisions like that sometimes?
02:56 VanessaE I went through that in plants_lib for a while before I just went with a table, remember?
03:09 sapier left #minetest-dev
03:18 OWNSyouAll_DESKT joined #minetest-dev
03:18 OWNSyouAll_DESKT joined #minetest-dev
03:44 KingsleyT joined #minetest-dev
03:58 OWNSyouAll_DESKT joined #minetest-dev
04:13 Miner_48er joined #minetest-dev
05:04 OWNSyouAll joined #minetest-dev
05:15 OWNSyouAll joined #minetest-dev
05:20 OWNSyouAll_DESKT joined #minetest-dev
05:25 OWNSyouAll_DESKT joined #minetest-dev
05:27 OWNSyouAll joined #minetest-dev
05:32 OWNSyouAll joined #minetest-dev
05:45 OldCoder joined #minetest-dev
06:03 nore joined #minetest-dev
06:17 damiel joined #minetest-dev
06:25 KingsleyT joined #minetest-dev
07:03 e1z0 joined #minetest-dev
07:17 djdduty joined #minetest-dev
07:17 djdduty joined #minetest-dev
07:33 VanessaE joined #minetest-dev
08:02 darkrose joined #minetest-dev
08:13 thexyz mapgen v7 is broken https://gist.github.com/xyzz/ed6a340​431aafb384516/raw/1aff32580c9a5cf720​65e929ac9ca293414f8ecd/gistfile1.txt
08:19 e1z0 joined #minetest-dev
08:20 e1z0 joined #minetest-dev
08:23 e1z0 joined #minetest-dev
08:25 VanessaE inb4 hmmmm says "aw fuck it, I'm ditching that whole mess and starting over"
08:34 e1z0 joined #minetest-dev
08:44 mrtux joined #minetest-dev
09:12 sapier joined #minetest-dev
09:29 Gethiox2 joined #minetest-dev
09:38 werwerwer joined #minetest-dev
09:40 Calinou joined #minetest-dev
09:58 emptty joined #minetest-dev
10:37 31NAAB2G3 joined #minetest-dev
10:59 bas080 joined #minetest-dev
11:06 ImQ009 joined #minetest-dev
11:36 emptty joined #minetest-dev
11:37 jin_xi joined #minetest-dev
11:48 emptty joined #minetest-dev
12:01 PilzAdam joined #minetest-dev
12:25 kahrl joined #minetest-dev
12:51 john_minetest joined #minetest-dev
13:35 hmmmm joined #minetest-dev
13:43 emptty1 joined #minetest-dev
13:49 thexyz hmmmm: https://gist.github.com/xyzz/ed6a340​431aafb384516/raw/1aff32580c9a5cf720​65e929ac9ca293414f8ecd/gistfile1.txt
13:56 hmmmm thanks
13:57 sapier what tool is this?
13:57 thexyz sapier: clang with -fsanitize=address
13:57 thexyz sapier: CC=clang CXX=clang++ cmake .. -DCMAKE_CXX_FLAGS="-O1 -g -fsanitize=address -fno-omit-frame-pointer -fno-optimize-sibling-calls" -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address" -DENABLE_FREETYPE=1 -DRUN_IN_PLACE=1
13:58 sapier interesting :-)
13:58 thexyz then run ./bin/minetest 2> log, then when it crashes you should run asan_symbolize.py < log | c++filt
13:58 hmmmm in practice that shouldn'tve happened though
13:58 hmmmm p ought to be restricted to node_min an node_max there
13:58 sapier I hope that there aren't any bugs that really should happen :-)
13:59 emptty joined #minetest-dev
14:00 emptty2 joined #minetest-dev
14:01 thexyz aand when I try to enter some /command in the chat I get this https://gist.github.com/xyzz/c8af388​8a035258e8172/raw/3f4e5ab3b70e1587a0​72c27498baa882be578436/gistfile1.txt
14:01 hmmmm that's in irrlicht, we can't do anything about that
14:01 thexyz I don't understand this, how can it crash there?
14:01 thexyz no, it's our file
14:02 thexyz https://github.com/minetest/minetest/bl​ob/master/src/intlGUIEditBox.cpp#L1434
14:02 hmmmm oh
14:02 hmmmm *blinks*
14:02 sapier guess this should be fixed immediatly :-)
14:03 sapier some ppl are complaining about chat crashes this could be source
14:04 hmmmm thexyz, it can crash there because that intlGUIEditBox was freed at the time setTextMarkers was called
14:05 hmmmm in other words, irr::gui::CGUIEnvironment::postEventFromUser posted the event to an already-destroyed GUI object or w/e it takes
14:05 hmmmm already-destroyed IGUIEditBox
14:06 hmmmm I guess you need to somehow unbind the event before destroying that control
14:06 sapier guess someone forgets to tell irrlicht about deletion?
14:06 hmmmm that's like javascript except even worse
14:07 sapier you always have to care if you give away pointers to other threads that's a design principle of c/c++ :-)
14:07 hmmmm I mean irrlicht though, shouldn't it automatically unbind events on delete
14:08 sapier how to notice?
14:08 hmmmm destructor...?
14:09 sapier it's our own destructor so if we don't do it in there who shall do it?
14:09 hmmmm the parent class!
14:10 sapier that'd require a event handling base class ... not sure if this is part of irrlicht
14:11 sapier but yes a full featured toolkit should do it this way ... but irrlicht is quite limited as of toolkit features
14:11 sapier https://github.com/minetest/minetest/pull/1029 anyone to review this one? (fixes windows build and removes some waste from jthread)
14:20 iqualfragile joined #minetest-dev
14:20 VanessaE joined #minetest-dev
14:42 hmmmm how could a sem_wait or sem_post etc ever fail
14:42 hmmmm ah EINVAL
14:42 hmmmm the win32/jevent.cpp whitespace at the bottom, fix that!
14:43 hmmmm otherwise it looks fine
14:44 hmmmm I really dislike the way JThread works to be honest, it itself uses like 3 mutexes per thread for basically nonsense.  i do feel like some logic could be condensed
14:45 hmmmm so, thexyz, when did you get that last error exactly?
14:49 sapier I haven't had a look at jthread thread itself
14:50 thexyz hmmmm: what error?
14:51 thexyz with chat? it happens every time
14:51 hmmmm the intlGUITextBox or whatever
14:51 hmmmm when though
14:51 sapier hmmmm those mutexes jthread uses are necessary to provide it's interface
14:51 hmmmm menu?  in game?  formspec?
14:52 thexyz chat, > <thexyz> aand when I try to enter some /command in the chat
14:52 sapier continuemutex and continuemutex2 are used for startup synchronization while runningmutex is used for shared data access
14:52 thexyz in game
14:52 hmmmm oh
14:53 hmmmm sapier, exactly, which I think is stupid
14:53 hmmmm the interface itself is unnecessary
14:53 sapier no it isn't there are good reasons to do so
14:53 hmmmm a while back i was considering scrapping jthread entirely and just adding some things to porting.cpp for threads
14:54 sapier ok wait
14:54 sapier the api doesn't even support creating a thread while not starting it
14:54 hmmmm out of those three the only thing needed is runningmutex
14:55 hmmmm yeah, some logic would have to be changed I get that
14:55 sapier good god the more I look at it the more I think jthread was written by someone doing this the first time in his live
14:55 hmmmm i'm most worried about the overall cleanness of design
14:56 sapier but still one thing is implemented
14:56 sapier jthread ensures threads are created and don't stall in non created state
14:57 sapier once you return from start you can be sure your thread is up and running
14:59 hmmmm i suppose that's a good thing, yes, but i'd say a good threading design would make such synchronization unneeded
14:59 sapier no
14:59 john_minetest Happy first of december btw :)
15:00 sapier imho it's good design to NOT rely on os scheduling assumptions
15:00 hmmmm what?  today isn't a holiday
15:01 sapier think about last days 3 os 3 completely different error occurances for non threadsafe actions
15:01 hmmmm that was because of safe data access not being used, not because the thread didn't start up in time
15:02 sapier that doesn't make a difference ;-) making sure a thread is there after start is a good thing ... creating a thread isn't a lightweight operation either so those mutex locks don't change the overall performance
15:03 hmmmm of course not, it's simply uglier than i think it could be made
15:03 john_minetest sapier: But today is the first day on which you can open a calendar door. :)
15:04 sapier it's not ugly just more complex ... and as complexity is hidden within jthread why bother?
15:04 sapier calender door ... wait ... now I remember what I missed
15:06 john_minetest :D
15:06 sapier I prefere more complex but safe solutions to simplistic solutions I always have to consider how to use it ... at least if their performance is almost equal
15:07 sapier ok I removed the trailing newlines ... ready for merge?
15:08 NakedFury joined #minetest-dev
15:08 rubenwardy joined #minetest-dev
15:10 zat joined #minetest-dev
15:15 hmmmm dure
15:15 hmmmm sure*
15:18 Zeitgeist_ joined #minetest-dev
15:23 sapier ok pushing jthread fixes now
15:32 Akien joined #minetest-dev
15:39 salamanderrake joined #minetest-dev
15:55 Exio4 [21:59:50] <+ShadowNinja> goto == bad.
15:55 Exio4 why?
15:56 PilzAdam maybe he meant "goto bed"?
15:57 Taoki joined #minetest-dev
15:57 thexyz Exio4: are you genuinely wondering why goto is bad?
15:59 Exio4 it is just other 'tool', if you overuse exceptions, ifs, or other 'features'...
15:59 john_minetest What are you talking about?
16:00 john_minetest goto == bad <- That is no "=". It is a comparison.
16:00 john_minetest Wonder how minetest runs if you don't get such basic things ;P
16:04 Exio4 the IRC isn't C code
16:06 john_minetest minetest is C(++) code
16:06 john_minetest Also I don't know any language that uses "==" as assignment.
16:07 john_minetest It could also be seen as a triple assignment chain but then it would be "nothing is bad and goto is nothing"
16:08 thexyz wtf is going on here
16:08 john_minetest so goto is bad. But since there are a few bad things it is wrong semantics.
16:08 john_minetest thexyz: Discussing assignment vs. comparison.
16:08 hmmmm goto is fine, whoever told you it was bad is just parroting somebody's weaker assertion from the 60s about it being bad if overused just like anything
16:10 thexyz it's bad because it's easily overused
16:10 john_minetest goto should be left out whereever possible.
16:10 hmmmm my use case in the code sample that comment was made on is fine
16:10 thexyz by people who aren't really familiar with the language
16:11 thexyz yeah, i can agree that in this case it's okay
16:20 Exio4 thexyz: and same with exceptions, they can be easily overused
16:22 celeron55 anything can be overused; case closed
16:24 celeron55 (just imagine what kind of code someone from assembly/basic background might have written in C tens of years back in time, and then stop that and do something useful instead)
16:55 emptty joined #minetest-dev
17:13 Calinou joined #minetest-dev
17:25 Calinou joined #minetest-dev
17:27 Calinou joined #minetest-dev
17:29 mrtux joined #minetest-dev
17:42 OldCoder joined #minetest-dev
18:12 emptty joined #minetest-dev
18:23 damiel joined #minetest-dev
18:23 PilzAdam hmmmm, http://irc.minetest.ru/minet​est-dev/2013-11-30#i_3464526
18:30 EvergreenTree joined #minetest-dev
18:41 jin_xi joined #minetest-dev
18:48 PilzAdam sapier, https://forum.minetest.net/vie​wtopic.php?pid=120404#p120404
18:49 PilzAdam I noticed that too, when you click on a server or a world in the server tab then your nick and password get reset
18:51 sapier nick and password?
18:52 sapier I didn't verify how password behaviour was before but as of security point of view reseting password on server switch is best to do
18:52 sapier if not done you'd send the old servers password to whoever is at new server
18:53 Exio4 *** Error in `/home/exio4/sources/minete​st/build/../bin/minetest': double free or corruption (fasttop): 0x00007fffe8000950 ***
18:53 Exio4 is this known
18:53 Exio4 a double free error in master
18:54 ShadowNinja sapier: I beleive the password is sent hashed.
18:55 PilzAdam sapier, no, its just annyoing that clicking somewhere else changes the textfields
18:57 sapier security is always annoying thats not a reason
18:57 thexyz Exio4: is that reproducible?
18:57 PilzAdam sapier, how is a hashed password a security risk?
18:58 thexyz you can use it to login to any minetest server
18:58 thexyz so that's a security risk
18:58 sapier the hash is the only secret user has
18:58 sapier knowing password and username is enough to enter
18:59 thexyz but that's extremely inconvenient — I enter my nickname, password, then click some server and then I have to enter everything again
18:59 thexyz well it's not like minetest's the most secure thing ever
18:59 Exio4 thexyz: no idea, i'm getting random crashes and one of them was the double free, the other was one repated by john_minetest before
18:59 thexyz Exio4: you could try running debug build in gdb or running debug build with clang address sanitizer
19:00 sapier no I don't say its save at all ... but if we don't at least try to not tell everyone users credentials we can just skip them
19:00 sapier it's even more comfort not having to remember any password
19:00 Exio4 er
19:00 Exio4 i think i got a reproduceable crash
19:01 sapier great exio4 those are best ones to fix
19:02 Exio4 well, half of the time it is the same crash, and it is a different one that what i posted here
19:02 PilzAdam sapier, also I have the feeling that menu is slower since async, especially shutting down and starting a server/world
19:03 thexyz Exio4: please do what I asked you for
19:03 Exio4 thexyz: i'm uploading the log of thread apply all bt full
19:03 sapier as you say ... maybe sleep(1) isn't best idea ;-) ... some ms should be enough there
19:04 thexyz sapier: was the mingw build issue sfan5 was experiencing fixed in the end?
19:05 Exio4 http://dpaste.com/1489385/ ?
19:05 sapier mingw is broken and I wont fix it IMHO it's waste of time supporting 5 incompatible compilers at same os
19:05 thexyz alright be prepared for butthurt then
19:06 sapier and it's NOT broken because of things I added it's broken by design
19:07 thexyz i'm not even asking you to fix it
19:07 sapier ppl keep on telling windows in source what windows version it is ... I guess windows itself would know best but usually I'm wrong
19:09 Exio4 i got the same bug when pressing play
19:09 Exio4 :(
19:09 sapier latest master exio?
19:09 Exio4 should be
19:10 Akien joined #minetest-dev
19:10 sapier guess there's still something left ... is anything within minetest threadsafe?
19:10 sapier :-)
19:11 sapier can you compile -O0 and reproduce this one exio?
19:11 Exio4 the only differences between my build and upstream, http://dpaste.com/1489393/
19:11 Exio4 it wasn't latest pull
19:11 sapier ok then update
19:12 sapier I fixed some errors quite similar to this one last night
19:12 Exio4 ah
19:12 Exio4 the jthread cleanup?
19:12 sapier no the log thread registry thing
19:13 sapier jthread cleanup is win32 build and as I was touching it I removed useless code too
19:14 Exio4 btw, how do i build with "-O0"? i added it to CXXFLAGS with cmake-gui and it still said <optimized-out> :P
19:14 Exio4 (such a noob question)
19:14 sapier you need to modify CMakeLists.txt ... people in here keep thinking they can debug -O1 code ;-)
19:15 sapier maybe they can ... I can't I need to know whats going on
19:18 ShadowNinja cmake -DCMAKE_CXX_FLAGS='-O0' <-- I've seen something like this used.
19:18 sapier might work too yes
19:19 sapier there are many ways to do this
19:19 ShadowNinja Does CMAKE_BUILD_TYPE='Debug' set -O0?
19:19 IceCraft_ joined #minetest-dev
19:19 Exio4 no, -O1
19:20 sapier but I'd suggest updating to latest master first
19:21 IceCraft joined #minetest-dev
19:22 Exio4 yes
19:22 Exio4 seems like the double memory was the same as the other one
19:22 Exio4 i'm not getting it
19:23 IceCraft joined #minetest-dev
19:25 IceCraft joined #minetest-dev
19:27 ImQ009 joined #minetest-dev
19:27 IceCraft joined #minetest-dev
19:29 IceCraft joined #minetest-dev
19:29 EvergreenTree joined #minetest-dev
19:31 IceCraft joined #minetest-dev
19:33 IceCraft joined #minetest-dev
19:36 emptty joined #minetest-dev
20:00 sfan5 thexyz: may I push http://pastebin.aquilenet.fr/?24b2ba01f2dbd61d​#vgZkWWVCRew3+Q0+V+OpJy0zp4eNMcYV3JRTqgdUoJM= ?
20:00 john_minetest Javascript is required for ZeroBin to work.
20:00 john_minetest Sorry for the inconvenience.
20:01 thexyz sfan5: if that works for you then why not
20:01 thexyz if that breaks msvc build then I'll fix that eventually
20:01 thexyz but it seems it should work
20:01 sfan5 well... as long as MSVC does define _WIN32 it works
20:01 thexyz but, I thought sapier has decided to decrease the sleep time
20:02 thexyz sfan5: so you should rewrite it to use usleep and also decrease the interval
20:02 thexyz 100 ms should be fine
20:02 sfan5 can you say these things before you say "then why not"
20:02 sfan5 I already pushed
20:02 thexyz sfan5: nah, that's fine, then leave it as is
20:03 thexyz john_minetest: your comment doesn't add anything meaningful to the conversation
20:03 thexyz john_minetest: can you please refuse from posting comments like that in the future?
20:07 Calinou joined #minetest-dev
20:11 damiel joined #minetest-dev
20:11 damiel joined #minetest-dev
20:15 Gethiox joined #minetest-dev
20:35 sapier please test ... https://github.com/minetest/minetest/pull/1030 ... I was annoyed about empty search tab
20:37 john_minetest thexyz: I would like to _see_ the changes that happen in minetest without the need to activate some dumb script that might spy on me or do anything. pastebin.com or gist are script-free.
20:39 thexyz john_minetest: I would like to not see messages that add nothing to conversation here; I don't care about your views on javascript and shit. Moreover, that message wasn't even addressed on you. So please can we stop with the retardity? Compalining for the sake of complaining is not welcome here.
20:40 thexyz I believe no one here cares if you have javascript enabled or not.
20:42 sfan5 john_minetest: how would a script spy on you?
20:43 Calinou pastebin.com has ads though :P
20:44 thexyz and here it goes
20:46 john_minetest gist hasn't ads. Also when using raw mode in pastebin, no ads are displayed for the viewer. The point I wanted to make is, that it isn't good to use image pastebins that require JS or flash or anything. It is just annoying.
20:48 john_minetest left #minetest-dev
21:02 thexyz the only one who's ever got annoyed by this just left this channel
21:02 Gethiox joined #minetest-dev
21:02 sapier1 joined #minetest-dev
21:43 fairiestoy joined #minetest-dev
21:56 ImQ009 joined #minetest-dev
22:34 PilzAdam sapier, https://github.com/minetest/minetest/pull/1031 is good
22:34 PilzAdam why did you make it 1 second in the first place?
22:35 smoke_fumus joined #minetest-dev
22:37 kahrl why not use sleep_ms?
22:38 kahrl btw, the include guard for this file should start with L_ and not C_
22:44 sapier I didn't realize this would cause delays in startup ... and as of closing something I usually don't care if it's 1s or 2 :-)
22:45 PilzAdam I havent noticed it at startup
22:45 PilzAdam but the menu also "closes" when you start a world.... and I guess you see the problem there
22:45 sapier that's what I meant with "startup"
22:46 kahrl imho it would be better if we used a JThread method that called either pthread_join or WaitForSingleObject
22:46 sapier kahrl thanks
22:48 sapier pthread_join and waitforsingleobeject aren't exactly compareable are they?
22:49 kahrl how so?
22:49 sapier pthread_join is a thread function is single object thread bound too?
22:49 sapier I don't know that much about win32 api
22:50 kahrl it can wait on any handle that supports some kind of "signaled" state
22:50 kahrl threads are signaled when they terminate
22:50 sapier then this might be an option too yes
23:04 sapier kahrl this way?
23:20 kahrl seems good, maybe check for errors
23:21 zat joined #minetest-dev
23:21 kahrl sapier: ^
23:22 kahrl I don't know if they should be treated as fatal errors (using assert) or just written to stderr
23:22 kahrl fatal is probably safer
23:22 sapier if we can't rely on threading we should stop
23:22 kahrl yeah
23:27 kahrl maybe write a comment somewhere that Wait() may only be called after Start() and not after Kill()
23:31 kahrl hold on a sec
23:32 kahrl in the pthread implementation, jthread creates the threads a detached
23:32 kahrl which means they can not be joined
23:32 kahrl as*
23:32 sapier ?
23:32 sapier it does work for me?
23:32 kahrl maybe some implementation artifact?
23:33 sapier as far as I know threads aren't detached by default
23:33 kahrl pthread/jthread.cpp:87
23:34 sapier oops
23:35 sapier ok wait I guess I forget to compile prior testing the asserted version
23:36 sapier jthread is crap ... using pthread_cancel as default shutdown mechanism ...
23:37 BlockMen joined #minetest-dev
23:37 kahrl indeed... wtf
23:38 sapier it's pure luck this doesn't crash evertim we close a thread
23:38 sapier I switch to non detached mode and cleanup in destructor maybe this works
23:39 BlockMen celeron55, here is the template for the subpages, currently without the fading out effect of the blue lines
23:39 kahrl well we do make sure every thread terminates in an orderly fashion before we destruct the corresponding JThread
23:39 sapier we can't without touching all threads
23:39 kahrl so pthread_cancel is not actually called
23:39 sapier do we?
23:40 kahrl I thought we did
23:40 sapier I haven't had a look at any single thread ;-) but I'd not be surprised if we didn't do
23:40 sapier ok I just remove the detached I don't have any idea what this should be good for
23:40 kahrl no
23:41 kahrl that creates a memory leak for every thread that Wait() isn't called on
23:41 sapier destructor ;-)
23:41 kahrl the destructor does nothing if running == false
23:42 sapier running is true as of thread has been started
23:43 kahrl if the thread terminates itself (as it should) it sets it to false again
23:44 sapier ok you're right
23:44 sapier so another variable
23:45 kahrl honestly we could just require that every thread is Wait()-ed on
23:46 kahrl btw, is it possible to consolidate SimpleThread and JThread?
23:47 sapier if we can hide this detail within jthread we should do
23:48 sapier I don't know but I guess we could as we already modified jthread that much
23:50 kahrl just wait in the destructor if the thread is running?
23:50 kahrl after killing it
23:51 sapier a little bit more to do but I guess I have a working solution now
23:54 sapier ok I hope I didn't miss a case ... do we have to do same things on windows too?
23:55 sapier I guess I should rename runningmutex to statusmutex
23:58 sapier that's not good now "kill" wont do what name tells any longer
23:58 kahrl just remove Kill() from the public interface
23:58 kahrl it's only needed in the destructor

| Channels | #minetest-dev index | Today | | Google Search | Plaintext