IRC logs for #opendune on OFTC at 2013-01-21
⏴ go to previous day
00:19:52 <TrueBrain> it only sucks that threading for linux is a pita
00:20:00 <TrueBrain> really wanted to avoid needing pthread in the project
00:21:50 <glx> yes on windows threading is easy
00:22:03 <glx> even if threads are not posix ones
00:22:06 <TrueBrain> I am very unsure if I want to put Linux through that ...
00:22:13 <TrueBrain> maybe make it so you can have Music with pthread
00:22:19 <TrueBrain> and without pthread, you simply don't have music
00:22:27 <TrueBrain> sounds like a fair trade-off to me
00:22:39 <TrueBrain> (as for linux too, you need the MPU in a thread to work correctly)
00:22:47 <TrueBrain> btw, you might need to add locking
00:23:03 <TrueBrain> as it might happen that the MPU static buffer is changed in the main thread, while the MPU thread is readnig it
00:23:10 <TrueBrain> or .. hmm .. I did check for this ...
00:23:19 <TrueBrain> no, MPU sets a boolean to true AFTER it sets all memory correct
00:23:22 <TrueBrain> so it should never be any issue
00:23:32 <TrueBrain> worst case is that the MPU timer might be one cycle late
00:23:53 <glx> unless the change happens while it's already inside the interrupt
00:24:32 <glx> (that probably caused the crash I had on exit)
00:25:01 <TrueBrain> even then it should never be an issue
00:25:02 <glx> data cleared while the interrupt was running
00:25:13 <TrueBrain> ah, no, but it should never clear data
00:25:22 <TrueBrain> or do I remember wrong .. hmm .. no, the thread itself should clean up any data
00:26:06 <glx> the thread only reads the data
00:26:23 <glx> which is set and cleared by the game
00:26:35 <TrueBrain> I only checked starting of the music indeed
00:26:54 <glx> there's no problems with the timer as main thread is suspended
00:29:05 <TrueBrain> I guess you can make something that waits for MPU_Stop to get an ack from the MPU thread
00:29:08 <TrueBrain> before doing CleanDAta
00:29:32 <glx> though if I read the code correctly MPU_ClearData() don't clear if music is playing
00:29:53 <TrueBrain> MPU_Stop() sets isplaying to false
00:30:45 <TrueBrain> I guess a simply mutex would solve it then
00:30:53 <TrueBrain> one around MPU_Interrupt in the thread
00:30:59 <TrueBrain> and in all the functions that write to data->
00:31:05 <TrueBrain> so they are not both active at the same time
00:31:14 <TrueBrain> the question is, can that reintroduce a deadlock ...
00:31:25 <TrueBrain> it shouldn't; the main thread is fully busy with the MPU
00:31:33 <TrueBrain> and so there is no weird context switching
00:32:03 <TrueBrain> ClearData should: - Wait for MPU thread to finish, lock the MPU thread, change the data, resume the MPU thread
00:32:41 <TrueBrain> at least, seems the easiest solution to me :P
00:32:48 <TrueBrain> but it is 01:32 here ... I might be wrong :D
00:33:00 <TrueBrain> I am off to bed; have an exam tomorrow. Ugh.
00:37:02 <glx> ClearData can't wait for the thread to finish because it may be called from the thread
01:49:20 <glx> ok after more analysing of the code the problem is not ClearData
01:49:44 <glx> it's the order of stuff in Drivers_SoundMusic_Uninit()
01:51:47 <glx> it's done in the reverse order of Drivers_SoundMusic_Init() which seems logical
01:52:21 <glx> but freeing buffers before shutting down MPU is indeed not a good idea :)
14:43:30 <TrueBrain> I would say: go for it
14:43:38 <TrueBrain> when I am back from my holiday I will work on the pthread stuff
15:06:18 <glx> now opendune always works on first start
15:06:19 <TrueBrain> now only DSP should put in a thread too
15:06:47 <glx> it used to hang at start du to file access in main while MPU was doing things
15:07:21 <TrueBrain> I wonder if pthread also solves linux issues
15:08:06 <TrueBrain> there the issue ofc is slightly different, where the SDL also fucks up memory stuff :P
15:08:37 <glx> timer now only does timer_tick (counter increment) and video_tick
15:08:55 <TrueBrain> videotick is a deadlock on linux too
15:09:04 <glx> and on windows video_tick doesn't require any lock I think
15:09:58 <TrueBrain> yeah; SDL can cause a malloc
15:10:01 <TrueBrain> which ofc is a real issue
15:11:38 <glx> on windows the only memory access are memcmp and memcpy, and memcpy copies stuff to static memory in the thread so it should be ok
15:11:58 <glx> else deadlocks would be more frequent ;)
15:12:04 <Xaroth|Work> ooh, just noticed
15:12:09 <Xaroth|Work> only 3 bugs away from 0.8 :o
15:12:16 <Xaroth|Work> I should check the milestone list more often
15:12:37 <glx> and would have happen before sound/music implementation
15:12:39 <TrueBrain> I did my best last weekend, yeah
15:12:44 <TrueBrain> now it will go silent for 2 weeks ... ;)
15:13:02 <TrueBrain> glx: the main thread doesnt do much malloc etc after startup
15:13:09 <TrueBrain> so on linux you only notice it because of the music
15:13:20 <TrueBrain> (ALSA driver mostly)
15:13:29 <TrueBrain> so I think both DSP and MPU will go in a pthread
15:13:34 <TrueBrain> and if you compile without it, you have no music
15:13:46 <TrueBrain> then ... we can move video_tick in all sleepIdle loops
15:13:59 <TrueBrain> and we can remove the signal code
15:14:09 <TrueBrain> hmm, no, we need it for timer_tick
15:14:15 <TrueBrain> but htat is okay, it then is trivial code
15:15:20 <glx> because removing signal stuff will be almost impossible
15:15:33 <glx> the code is clearly no written for it
15:15:49 <TrueBrain> and for only adding stuff to globals, it is fine
15:17:03 <glx> the only thing that can happen now is a little desync in music but it doesn't really matter ;)
15:22:06 <glx> no sure you can put DSP in a thread, but if video_tick is moved to sleepIdle() it should no longer be a problem as DSP and SDL will be in the same thread
15:22:52 <glx> and having MPU in a thread should be enough then
15:25:31 <TrueBrain> I guess you are right
15:25:35 <TrueBrain> SDL makes a thread for DSP
15:25:40 <TrueBrain> but that I leave fully up to SDL to do
15:26:35 <glx> the current problem is clearly memory access in the signal handler :)
15:26:54 <TrueBrain> come to think of it, as other solution we can use SDL threads
15:27:04 <TrueBrain> which is fine as long as we dont have an alternative video driver for linux anyway
15:27:17 <TrueBrain> I do want to add pthread, but that doesn't have to be done right this instance
15:27:32 <TrueBrain> so then we can move MPU to a thread too
15:27:41 <TrueBrain> and move video_tick to sleepIdle (or rather, call video_tick in those loops)
15:28:05 <TrueBrain> then linux and windows are on par again
15:30:53 <glx> looking at SDL API it can be done exactly like on windows, ie create a thread and a semaphore
15:32:35 <TrueBrain> exactly what I Was hoping for :)
15:34:10 <TrueBrain> do you want to give that a try?
15:34:15 <TrueBrain> otherwise I will hopefully later tongiht :)
15:34:56 <TrueBrain> I also have to boot a VM for that ;) But it is fine either way :)
continue to next day ⏵