From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HZ4ZG-00047u-15 for qemu-devel@nongnu.org; Wed, 04 Apr 2007 08:26:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HZ4ZE-00047a-Mh for qemu-devel@nongnu.org; Wed, 04 Apr 2007 08:26:24 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HZ4ZE-00047I-9L for qemu-devel@nongnu.org; Wed, 04 Apr 2007 08:26:24 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HZ4Vx-0006HH-QQ for qemu-devel@nongnu.org; Wed, 04 Apr 2007 08:23:02 -0400 Received: by wx-out-0506.google.com with SMTP id i30so284817wxd for ; Wed, 04 Apr 2007 05:23:01 -0700 (PDT) Message-ID: Date: Wed, 4 Apr 2007 14:23:00 +0200 From: "andrzej zaborowski" Sender: balrogg@gmail.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_26832_19131845.1175689380761" References: Subject: [Qemu-devel] Re: SDL audio and AIO hogging each other's signals Reply-To: balrogg@gmail.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: qemu-devel@nongnu.org ------=_Part_26832_19131845.1175689380761 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 04/04/07, malc wrote: > On Wed, 4 Apr 2007, andrzej zaborowski wrote: > > > Hi, thanks for quick response! > > > > On 03/04/07, malc 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 > > The signal state of the new thread is initialised as follows: > > * The signal mask is inherited from the creating thread. > 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 ------=_Part_26832_19131845.1175689380761 Content-Type: text/plain; name=0001-Ensure-signals-are-properly-masked-for-new-SDL-Audio-threads.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_f03t2yve Content-Disposition: attachment; filename="0001-Ensure-signals-are-properly-masked-for-new-SDL-Audio-threads.txt" RnJvbSA2ODQzMzk5ZTVlNzUxZTk5OWYzM2RlMDllNDQ3NmY3Yzk2ODM5OTc0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBbmRyemVqIFphYm9yb3dza2kgPGJhbHJvZ0B6YWJvci5vcmc+ CkRhdGU6IFdlZCwgNCBBcHIgMjAwNyAxNToxODoyMCArMDIwMApTdWJqZWN0OiBbUEFUQ0hdIEVu c3VyZSBzaWduYWxzIGFyZSBwcm9wZXJseSBtYXNrZWQgZm9yIG5ldyBTREwgQXVkaW8gdGhyZWFk cy4KCi0tLQogYXVkaW8vc2RsYXVkaW8uYyB8ICAgMTggKysrKysrKysrKysrKysrKysrCiAxIGZp bGVzIGNoYW5nZWQsIDE4IGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0 IGEvYXVkaW8vc2RsYXVkaW8uYyBiL2F1ZGlvL3NkbGF1ZGlvLmMKaW5kZXggZjJhNjg5Ni4uMTFl ZGFiMCAxMDA2NDQKLS0tIGEvYXVkaW8vc2RsYXVkaW8uYworKysgYi9hdWRpby9zZGxhdWRpby5j CkBAIC0yNSw2ICsyNSwxMyBAQAogI2luY2x1ZGUgPFNETF90aHJlYWQuaD4KICNpbmNsdWRlICJ2 bC5oIgogCisjaWZuZGVmIF9XSU4zMgorI2lmZGVmIF9fc3VuX18KKyNkZWZpbmUgX1BPU0lYX1BU SFJFQURfU0VNQU5USUNTIDEKKyNlbmRpZgorI2luY2x1ZGUgPHNpZ25hbC5oPgorI2VuZGlmCisK ICNkZWZpbmUgQVVESU9fQ0FQICJzZGwiCiAjaW5jbHVkZSAiYXVkaW9faW50LmgiCiAKQEAgLTE3 NywxMSArMTg0LDIyIEBAIHN0YXRpYyBpbnQgc2RsX3RvX2F1ZGZtdCAoaW50IHNkbGZtdCwgYXVk Zm10X2UgKmZtdCwgaW50ICplbmRpYW5lc3MpCiBzdGF0aWMgaW50IHNkbF9vcGVuIChTRExfQXVk aW9TcGVjICpyZXEsIFNETF9BdWRpb1NwZWMgKm9idCkKIHsKICAgICBpbnQgc3RhdHVzOworI2lm bmRlZiBfV0lOMzIKKyAgICBzaWdzZXRfdCBuZXcsIG9sZDsKKworICAgIC8qIE1ha2Ugc3VyZSBw b3RlbnRpYWwgdGhyZWFkcyBjcmVhdGVkIGJ5IFNETCBkb24ndCBob2cgc2lnbmFscy4gICovCisg ICAgc2lnZmlsbHNldCAoJm5ldyk7CisgICAgcHRocmVhZF9zaWdtYXNrIChTSUdfQkxPQ0ssICZu ZXcsICZvbGQpOworI2VuZGlmCiAKICAgICBzdGF0dXMgPSBTRExfT3BlbkF1ZGlvIChyZXEsIG9i dCk7CiAgICAgaWYgKHN0YXR1cykgewogICAgICAgICBzZGxfbG9nZXJyICgiU0RMX09wZW5BdWRp byBmYWlsZWRcbiIpOwogICAgIH0KKworI2lmbmRlZiBfV0lOMzIKKyAgICBwdGhyZWFkX3NpZ21h c2sgKFNJR19TRVRNQVNLLCAmb2xkLCAwKTsKKyNlbmRpZgogICAgIHJldHVybiBzdGF0dXM7CiB9 CiAKLS0gCjEuNC40LjMKCg== ------=_Part_26832_19131845.1175689380761--