qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: andrzej zaborowski
Subject: [Qemu-devel] Re: SDL audio and AIO hogging each other's signals
Date: Wed, 4 Apr 2007 14:23:00 +0200

On 04/04/07, malc <address@hidden> wrote:
On Wed, 4 Apr 2007, andrzej zaborowski wrote:

> Hi, thanks for quick response!
>
> On 03/04/07, malc <address@hidden> wrote:
>> On Tue, 3 Apr 2007, andrzej zaborowski wrote:

[..snip..]

> It should be using ALSA.
>
>>
>> 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.

Actually the signal can be just handled (by whatever signal handler
QEMU installed with sigaction) in a SDL created thread, so things can,
and mostlikely will, be silently wrong, i.e. EINTR while possible will
not necessarily happen.

>
> Yes, reading the PTHREAD_SIGNAL(3) note, this sounds very likely.
>
>>
>> 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?)
>
> Not really - just had only OSS and SDL compiled into qemu at this moment.
>
> Yes, the suggested solution works. Unfortunately it's neither pretty
> nor correct, because at the time sdl_callback runs, the signal which
> was supposed to wake up sigwait() is already lost and I can't find any
> way to prevent that - we can add a kill(0, SIGUSR2) but this is even
> uglier and again we don't know when sdl_callback is called as a result
> of this signal and when legally. (That's also why I didn't put a
> "return" after pthread_sigmask().)

[..snip..]

> What POSIX needs is a way to set the default signal mask for new threads :-/

http://www.opengroup.org/onlinepubs/007908799/xsh/pthread_create.html
in part reads
<quote>
The signal state of the new thread is initialised as follows:

     * The signal mask is inherited from the creating thread.
</quote>

Oh, right.


Hence sequence of:

sigfillset (newset)
pthread_sigmask (SIG_BLOCK, newset, oldset)
SDL_OpenAudio (...)
pthread_sigmask (SGI_SETMASK, oldset, NULL)

Will probably achieve the desired effect.

Thanks, this works!

Attached is a patch, should be safe to apply. We're still making the
assumption that the thread is created precisely in SDL_OpenAudio and
not later, but this should not be a problem because all signals in the
main thread should be blocked throughout the entire runtime.

Regards,
Andrzej

Attachment: 0001-Ensure-signals-are-properly-masked-for-new-SDL-Audio-threads.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]