IRC logs for #opendune on OFTC at 2012-12-27
⏴ go to previous day
13:34:59 *** DorpsGek` has joined #openDune
13:34:59 *** ChanServ sets mode: +o DorpsGek`
13:35:55 *** DorpsGek` is now known as DorpsGek
13:37:40 *** planetmaker has joined #openDune
13:37:40 *** graviton.oftc.net sets mode: +v planetmaker
13:48:11 *** planetmaker has joined #openDune
13:48:11 *** ChanServ sets mode: +v planetmaker
22:50:44 *** TrueBrain has joined #openDune
22:50:58 <TrueBrain> yesterday I spend a good time of my day tracing the deadlock issue with SDL and DSP
22:51:05 <TrueBrain> I fully understand the issue now
22:51:08 <TrueBrain> but a solution is rather hard
22:51:19 <TrueBrain> I thought the DSP was in a signal, and the SDL was in the main, but it is the other way around
22:51:31 <TrueBrain> and every DSP function can trigger the issue (or every SDL call, how ever you look at it)
22:51:41 <TrueBrain> I wanted to implement a simple locking mechanism
22:51:50 <TrueBrain> but that gets rather complex, as there are many potential places
22:52:12 <TrueBrain> that said, it is very hard to reproduce the error here without helping a hand; it seems to be much more likely on slower machines only
22:52:21 <TrueBrain> and relative bad implemented ALSA drivers
22:52:58 <glx> so combination of multiple factors
22:54:03 <glx> and the fact the game is controlled by timer
22:54:05 <TrueBrain> basically, the DSP is the only driver that writes in the main
22:54:15 <TrueBrain> the MTU and SDL both happen from the signal handler
22:54:33 <TrueBrain> the MTU it very funny in those regards: from the main everything is prepared and set ready
22:54:48 <TrueBrain> then the signal handler reads the data and sends it to the card
22:54:59 <TrueBrain> the DSP is different: the main sends the information directly to the card
22:55:05 <TrueBrain> (which can cause a malloc)
22:55:18 <TrueBrain> my first idea was to move that to a signal handler too, but I have no idea what the impact would be
22:55:53 <TrueBrain> next issue is that the DSP has a callback handler
22:55:56 <TrueBrain> for when the buffer runs low
22:56:00 <TrueBrain> which runs in its own signal handler
22:56:58 <TrueBrain> so easy solution is: lock around all DSP calls, for each driver
22:57:03 <TrueBrain> which means some screen updates are skipped
22:57:07 <TrueBrain> not the worst, I would imagine
22:57:20 <TrueBrain> better solution would be to move DSP to a signal handler ... not easy
22:57:27 <TrueBrain> perfect solution would be to remove signals all together
22:57:33 <TrueBrain> but .. well .. we know that is even harder :D
23:01:52 <glx> oh keeping signals for DSP should be ok if main thread doesn't use them
23:02:26 <TrueBrain> the API is very small, so that is easy
23:02:36 <TrueBrain> but it is not easy (read: a lot of code) to move the DSP to a signal handler
23:03:19 <TrueBrain> and I wonder if the callback function wouldn't give a problem
23:03:41 <TrueBrain> or that too can just flag something, that the signal handler will pick up on
23:05:05 <glx> on windows it's easy as the callback is called only when playing is done
23:05:22 <TrueBrain> on Windows the callback means: we are done!
23:05:25 <glx> and we can directly pass all the data
23:05:41 <TrueBrain> besides, Windows uses threads as signal handler
23:05:59 <TrueBrain> that would also work for Linux, but I don't really fancy adding pthread as requirement
23:06:11 <glx> but for alsa you are dependant on "system" buffer size
23:07:21 <TrueBrain> anyway, on a broader view on this problem: we cannot do any malloc/free/realloc in the main thread
23:07:27 <TrueBrain> as long as SDL is in the signal handler
23:07:38 <glx> I guess sdl dsp driver doesn't have this problem but it sounds ugly IIRC
23:08:10 <TrueBrain> so coming to think of it, solving the DSP only hides the problem (again)
23:09:05 <TrueBrain> it annoys me that I cannot do something like: if (malloc_lock) return
23:09:07 <TrueBrain> in the signal handler
23:09:09 <TrueBrain> I mean ... why not?!
23:16:43 <TrueBrain> so ... down to two options: use pthread, or move all code to a single main-loop
23:17:01 <TrueBrain> last one is a real issue, as the MTU will have a hard time playing nicely
23:17:10 <TrueBrain> MTU? Why do I keep saying MTU? Its called MPU or MT32 ...
23:20:36 <TrueBrain> I guess it would be fine to introduce pthread for MPU
23:20:44 <TrueBrain> as in, if you compile with pthread, you get MIDI music
23:20:47 <TrueBrain> if not, you don't get it
23:21:03 <TrueBrain> I can live with that ...
23:21:07 <TrueBrain> that would only leave SDL stuff
23:21:22 <TrueBrain> I guess strictly seen we can isolated the moments the screen is changed
23:21:26 <TrueBrain> and can insert updates there
23:21:29 <TrueBrain> instead of doing it in a signal
23:21:48 <TrueBrain> I believe that is one function that flips the screens, after which ofc we need to redraw
23:23:02 <TrueBrain> if you have any other suggestions, please let me know :D
23:23:17 <TrueBrain> else I will start (this weekend or so) this process of moving stuff out of the signal handler where possible
23:23:23 <glx> I'm no a linux specialist
23:23:27 <TrueBrain> and possibly only leave a small subset of internal updating :P
23:23:32 <TrueBrain> not really related to linux tbh :P
23:24:05 <glx> oh you mean the move timer->event loop
23:24:07 <TrueBrain> only important thing here is that 2 mallocs cannot happen from the main and signal handler ;)
23:24:25 <TrueBrain> we can also call that when the screen is changed
23:24:36 <TrueBrain> (well, ignoring the loop to look at events :P)
23:25:27 <TrueBrain> GFX_CopyToBuffer is one, as example :)
23:26:11 <TrueBrain> just a matter of finding the places, and calling a Video update function :)
23:26:42 <TrueBrain> then only SDL_PollEvent remains in the signal handler ... I guess that is not really bad
23:26:49 <TrueBrain> moving that would be even harder :P
23:27:43 <TrueBrain> then only the MTU remains in the signal handler ... and for WIndows we can thread that, and for Linux we can pthread that .. hmm
23:27:50 <TrueBrain> I think that would be a nice way to go forward to
23:28:09 <TrueBrain> also means we can use malloc/free a lot more in the main code
23:28:16 <TrueBrain> without being afraid of deadlocking :D
23:36:14 <TrueBrain> wasnt there a windows issue where windows needed something initialized int he thread it was being used?
23:37:01 <TrueBrain> or was that SDL, which we moved?
23:37:59 <TrueBrain> so Windows cannot even use SDL as video driver :P
23:38:09 <glx> for win32 window must be created in the thread where events are polled
23:38:27 <TrueBrain> yeah; so even if you force the SDL driver
23:38:30 <TrueBrain> it will not work :D
23:38:52 <TrueBrain> which we removed :)
23:38:56 <TrueBrain> great; then I know what to do :)
23:39:01 <TrueBrain> now only I have to do it .... lolz
23:39:07 <TrueBrain> not today; I am tired
23:42:56 <TrueBrain> lucky the instances are easy to find, as acecss to the screen buffer is always done with 1 function :)
23:47:57 <glx> but it's not always the visible screen
continue to next day ⏵