From: malc <av1474@comtv.ru>
To: balrogg@gmail.com
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: SDL audio and AIO hogging each other's signals
Date: Wed, 4 Apr 2007 15:49:28 +0400 (MSD) [thread overview]
Message-ID: <Pine.LNX.4.64.0704041536470.2248@linmac.oyster.ru> (raw)
In-Reply-To: <fb249edb0704040126u64e051f6j5c4c76abebf9eb18@mail.gmail.com>
On Wed, 4 Apr 2007, andrzej zaborowski wrote:
> Hi, thanks for quick response!
>
> On 03/04/07, malc <av1474@comtv.ru> 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>
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.
--
vale
next prev parent reply other threads:[~2007-04-04 11:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-03 21:12 [Qemu-devel] SDL audio and AIO hogging each other's signals andrzej zaborowski
2007-04-03 21:56 ` [Qemu-devel] " malc
2007-04-04 8:26 ` andrzej zaborowski
2007-04-04 11:49 ` malc [this message]
2007-04-04 12:23 ` andrzej zaborowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0704041536470.2248@linmac.oyster.ru \
--to=av1474@comtv.ru \
--cc=balrogg@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).