qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).