IRC logs for #opendune on OFTC at 2013-04-07
⏴ go to previous day
14:56:58 <glx> tried yet another solution for the deadlock problem
15:28:03 <TrueBrain> btw, github happily told us you cannot block users from a organization, you can only block users from another user .... lame? Hell yes!
15:28:20 <TrueBrain> anyway, how does your oslution solve OSX?
15:28:27 <TrueBrain> didnt it need events in the main thread?
15:31:00 <TrueBrain> (and your branch doesnt remove the video stuff from the signal handler, does it? So Linux still has issues, not?)
15:32:22 <glx> but audio is now in a different thread as it's done in GameLoop_Main loop
15:32:56 <TrueBrain> but the problem is that audio happens in 1 thread, while video happens in a signal
15:33:00 <TrueBrain> and malloc is not reentrant
15:33:09 <TrueBrain> so if audio triggers a malloc, and the signal is acitvated
15:33:12 <TrueBrain> ahd there a free happens
15:33:20 <TrueBrain> so I dont really get how your solution should solve that?
15:34:51 <TrueBrain> hmm ... but with your patch
15:34:56 <TrueBrain> cant you then remove the signal
15:35:02 <TrueBrain> as you can just while(true) {} the main loop
15:35:16 <glx> ha right, let's try that :)
15:35:44 <TrueBrain> but does that solve OSX? As events now too are done in the GameLoop_Main thread?
15:35:48 <TrueBrain> or are events done in the signal handler?
15:36:07 <TrueBrain> but yeah, then this solution is kinda the inverse of your other :P
15:36:17 <TrueBrain> should solve the issue I guess, although it is rather ugly :D
15:36:34 <glx> well while (!Semaphore_TryLock(s_main_sem)) sleepIdle(); could simply run video_tick
15:36:40 <TrueBrain> but it is clean, and easily resolved later with a proper solution if the time gets there ...
15:36:57 <TrueBrain> as long as they lock eachother ofc
15:37:19 <TrueBrain> (so that in multi-core systems, not both video_tick and GameLoop_Main runs
15:38:06 <glx> dunno, for now main thread just wait for gameloop thread to finish (waiting for the lock without blocking)
15:38:47 <glx> so the effect should be similar to the video thread try
15:39:16 <TrueBrain> well, funny enough, Dune2 is not thread-safe
15:39:22 <glx> with just exchanged main and vido threads
15:39:22 <TrueBrain> its drawing routine can be done midway
15:39:38 <TrueBrain> how Dune2 solves that is preparing everything, and then doing a copy at once
15:39:44 <TrueBrain> so I guess we should be fine-ish
15:39:49 <TrueBrain> but the solutions are not elegant ..
15:40:38 <TrueBrain> then again, I am also running out of ideas :P
15:52:17 <glx> ok moved Video_Thread outside signal handler
15:53:57 <glx> and I'll ignore the comment of the other guy ;)
15:55:19 <glx> we know we theorically should lock accesses but it should work without that
15:55:32 <TrueBrain> its how Dune2 was built, so yeah
15:55:38 <TrueBrain> does you branch work now? (I cant test :( )
15:55:44 <TrueBrain> as in, on Windows and Linux?
15:55:59 <glx> I tried on windows, linux VM and OSX VM
15:56:17 <glx> but as already stated I never encountered the deadlocks in VMx
15:57:15 <glx> the only problem I have in OSX VM is choppy sound
15:57:26 <glx> but that's not related to opendune
16:02:51 <glx> hmm if thread creation fails there will be a problem
16:03:43 <glx> (no Video_Tick at all ;) )
16:27:30 <TrueBrain> how about removing the whole signal stuff
16:27:35 <TrueBrain> and just calling the signal handler
16:27:40 <TrueBrain> instead of only the videotick?
16:27:56 <TrueBrain> as it feels weird now, that the signal is called while it is in such basic while(true) loop ;)
16:34:21 <glx> hmm so keep Timer_Add calls how it was, and call Timer_InterruptRun from the loop with a sleep corresponding to signal timer ?
16:34:34 <TrueBrain> and remove all the signal code
16:34:39 <TrueBrain> wouldnt that make more sense?
16:34:52 <TrueBrain> basically your patch then makes the signal the main thread, and the game a sub thread
16:34:57 <TrueBrain> solving OSX and Windows issues
16:35:01 <TrueBrain> and the Linux reentrant issue
16:35:21 <glx> should solve all issues yes
16:37:44 <glx> and just abord it thread creation fail then
16:44:51 <TrueBrain> if thread creation fails
16:44:55 <TrueBrain> it falls back to signal stuff
16:44:59 <TrueBrain> presents a warning to the user
16:45:03 <TrueBrain> and disables music+sound
16:45:16 <TrueBrain> that should aviod the reentrant issue (For now at least)
16:48:35 <glx> hmm we can just call Timer_Tick() and Video_Tick() in the loop indeed
16:52:26 <TrueBrain> you have to call the interrupt handler
16:52:30 <TrueBrain> it handles if sometimes things are too slow
17:08:15 <TrueBrain> (And I guess it is cleaner if you do the signal as fallback method)
17:31:40 <glx> oups forgot to uncomment a line
17:33:48 <glx> I tested both cases on windows
17:34:38 <TrueBrain> but yeah, that patch is what I meant; seems a cleaner solution
17:43:28 <glx> ok will now unpush the 2 latest commits ;)
19:29:18 <glx> hmm weird now it fails on OSX
continue to next day ⏵