IRC logs for #opendune on OFTC at 2013-01-20
⏴ go to previous day
12:59:02 <TrueBrain> your patch, you are basially saying they used a complex function to do something easy, or what is going on?
12:59:33 <glx> the function can do different things depending on the mask passed
12:59:56 <glx> but as they always pass 0xFFFF or 0xFF the result is always the first arg
13:00:42 <glx> for the static variable it the same it's always 0
13:02:20 <glx> probably some kind of API
13:04:15 <glx> silly github, I can't sync with uncommited changes
13:04:29 <TrueBrain> a rather annoying one
13:04:33 <TrueBrain> you can via the shell
13:05:09 <planetmaker> it refuses for me to rebase w/o commit also on command line
13:06:02 <glx> git pull seems to hav worked :)
13:06:18 <planetmaker> but that means your checkout didn't change
13:31:47 <glx> pff there's a lot of duplication between GameLoop_Main() and GameLoop_static void GameLoop_GameIntroAnimationMenu()
14:17:49 <TrueBrain> glx: what o you think about increasing the harvested amount in the score
14:17:52 <TrueBrain> itis now capped at 65k
14:17:59 <TrueBrain> I am not sure ... I really like that somehow
14:18:07 <TrueBrain> but the reason for that limit is only because it is stored as a 16bit on disk
14:19:10 <glx> it shouldn't be too hard to increase properly I think
14:19:45 <TrueBrain> ODUN is only for units
14:19:48 <TrueBrain> but I can just add a new chunk
14:19:56 <TrueBrain> I am just not sure if I really want to .. that is a bit the issue :P
14:20:12 <glx> oh that can wait I guess :)
14:20:27 <TrueBrain> it is rather classic dune2 to have that limit
14:20:44 <TrueBrain> same goes for your max credits
14:58:42 <glx> but I get more deadlocks in intro or menu :(
15:02:00 <TrueBrain> well, as long as you are sure the deadlocks are the same, and not new ones .. ;)
15:02:24 <glx> and they are still "random"
15:04:59 <glx> black screen with only music but when I press a key the menu appears
15:13:29 <glx> I remove TIMER_GUI enabling
15:29:32 <glx> ok caching some File_Exists() results seems to reduce menu deadlocks
15:30:02 <glx> (of course redoing the call in each loop is not very good ;) )
15:58:58 <glx> seems stable, menu is running for more than 5 minutes now without deadlocking
16:00:00 <glx> lol deadlock when clicking "play"
16:06:18 <glx> indeed the deadlocks are not really between MPU and DSP, but between MPU and other memory alloc/free
17:02:14 <TrueBrain> hmm, on Windows they should be rare
17:02:17 <TrueBrain> as Windows uses threads
17:02:24 <TrueBrain> so hmm .. yeah, it can still deadlock eachother
17:02:40 <TrueBrain> on Windows it didnt happen very often
17:05:37 <glx> for now I have mpu thread waiting for main thread, an main thread waiting for something else (still trying to find what in wingdb)
17:07:29 <glx> hmm theres another thread waiting for mpu
17:26:10 <glx> should be one of the usual random deadlock
20:44:09 <glx> after more testing it's clearly a "random" deadlock, like the others
20:45:55 <glx> probably caused by bad luck/timing, like when timer interrupt happens in the middle of a memory allocation/deallocation
20:49:46 <glx> "Calling SuspendThread on a thread that owns a synchronization object, such as a mutex or critical section, can lead to a deadlock if the calling thread tries to obtain a synchronization object owned by a suspended thread."
20:50:08 <glx> seems it's exactly our situation ;)
20:50:26 <Xaroth|Work> you actually managed to find something useful on msdn?!?
20:50:50 <glx> yes MSDN always has useful stuff
20:51:03 <Xaroth|Work> yeh, but finding it can be an absolute pita
20:51:17 <glx> but you first need to know what to search for :)
20:51:51 <glx> (in this case I just pressed F1 on SuspendThread() call in our code ;) )
21:10:18 <glx> so it seems windows and linux are victims of the same phenomenon
21:13:07 <glx> as on windows opendune handles timer like a signal, ie suspend main thread, execute interrupt, resume main thread
21:15:02 <TrueBrain> so how are we going to solve that .... ugh
21:15:12 <TrueBrain> also there: remove threads
21:15:47 <glx> threads are not a problem, it's the way we use them :)
21:16:49 <glx> "This function is primarily designed for use by debuggers. It is not intended to be used for thread synchronization." <-- SuspendThread() doc is clear about it :)
21:17:23 <glx> the next line in the doc is the one I pasted earlier
21:21:46 <glx> the only solution is really to remove timer, and it won't be easy to do
21:22:41 <glx> anyway merging menu loop and main loop seems to work correctly so I think I'll commit it
22:00:31 <glx> hmm what could happen if we remove MPU interrupt from timer stuff and just put it in its own thread doing infinitely MPU_Interrupt() then sleep for (1000000 / 120) usec ?
23:11:58 <glx> ha but a crash on exit is not good
continue to next day ⏵
