[Qemu-devel] Re: SDL audio and AIO hogging each other's signals

[malc]

On Tue, 3 Apr 2007, andrzej zaborowski wrote:

> Hi,
> with QEMU_AUDIO_DRV set to "sdl" and booting from CD-ROM with AIO on
> a Linux host and with SDL 1.2.11, qemu locks up in sigwait() (the main
> thread) and SDL_SemWait() (the audio thread) as soon as music is
> playing and CD-ROM is being read at the same time. It appears that
> audio/sdlaudio.c:sdl_callback is called by SDL when it shouldn't be
> called, and block-raw.c is trying to flush the AIO operations, so it
> would seem that the SIGUSR2 which is intended to wake up the sigwait
> is instead captured by SDL and SDL tries to be smart and calls
> sdl_callback. sdl_callback has a sanity check but this check is
> *after* SDL_SemWait() so it is not triggered. The strange thing is
> that using a different signal (tried SIGUSR1 and SIGPOLL) for AIO
> doesn't help. Does SDL catch all signals?
> I could be totally wrong because I don't know SDLAudio at all.

If my reading of SDLs sources are correct then it shouldn't be trying
to catch any signals when explicitly instructed not to do so (which is
done in sdl.c (SDL_INIT_NOPARACHUTE flag)).

> Any ideas about the exact reason why this is happening and how to fix it?

Given the semantics of signal delivery in POSIX what you describe
might happen, what is a little surprising is that SDL (btw. which
backend SDL uses?) doesn't complain.

Here's my theory: signal will be delivered to the arbitrary thread
that happens to not block it, for whatever reason, the thread SDL
created to do audio processing is picked up, which leads to some
system call being interrupted(eventually) and -1 (errno == EINTR), SDL
happily continues calling stuff.

One solution would be to explicitly block everything upon entering
sdl_callback for the first time. This is ugly and can have any
consequences one cares to imagine, but that's SDL for you (any
particular reason why you are using it?)


P.S. Quoting PTHREAD_SIGNAL(3)

NOTES
       For !sigwait! to work reliably, the signals being waited  for  must  be
       blocked in all threads, not only in the calling thread, since otherwise
       the POSIX semantics for signal delivery do not guarantee that it's  the
       thread  doing the !sigwait! that will receive the signal.  The best way
       to achieve this is block those signals before any threads are  created,
       and  never unblock them in the program other than by calling !sigwait!.

--
vale