qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/3] coroutine: adding sigaltstack method (.c so


From: Alex Barcelo
Subject: Re: [Qemu-devel] [PATCH 1/3] coroutine: adding sigaltstack method (.c source)
Date: Tue, 14 Feb 2012 14:21:57 +0100

On Tue, Feb 14, 2012 at 13:20, Stefan Hajnoczi <address@hidden> wrote:
> On Tue, Feb 14, 2012 at 11:53 AM, Alex Barcelo <address@hidden> wrote:
>> On Tue, Feb 14, 2012 at 10:24, Stefan Hajnoczi <address@hidden> wrote:
>>> (...)
>>> What happens when a vcpu thread creates a coroutine while another QEMU
>>> thread raises SIG_IPI?  The SIG_IPI will be handled on the alternate
>>> signal stack
>>
>> mmm no, it won't. The sigaction is set for the SIGUSR1 only (yes I
>> have to change it to sigusr2, the V2 will have this changed). And only
>> this signal will be handled on an alternate stack (the sa.sa_flags is
>> the responsible).
>>
>> I'm not really sure about that, did I miss something?
>
> What I meant is that there are other signals handlers installed and
> the signals will be unblocked between the time when sigsuspend() has
> returned and before sigaltstack(NULL, &ss) is executed.  This seems
> like a race condition to me.

But nobody (in qemu) uses sa.sa_flags ONSTACK, so I see no problem. If
a signal is delivered, it will be attended as it should. If there is
some other sigaltstack (I looked for it, and found nothing) then you
are right. But if no other signal uses sigaltstack, then there is no
race condition between the sigaltstack and the sigsuspend. And we only
use a signal that should not be used anywhere else (I have to change
that, seems that SIGUSR1 is being used in some point). So no conflict
here.

Have I understood you? I'm not sure if this is what you were talking
about... if not, please, explain a bit more the race condition and the
exact problem.



reply via email to

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