On Tue, Feb 14, 2012 at 1:21 PM, Alex Barcelo <abarc...@ac.upc.edu> wrote: > On Tue, Feb 14, 2012 at 13:20, Stefan Hajnoczi <stefa...@gmail.com> wrote: >> On Tue, Feb 14, 2012 at 11:53 AM, Alex Barcelo <abarc...@ac.upc.edu> wrote: >>> On Tue, Feb 14, 2012 at 10:24, Stefan Hajnoczi <stefa...@gmail.com> 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.
No, you are right. It's not a problem because SA_ONSTACK isn't used elsewhere. Sorry, I missed that you need to set it explicitly on a per-signal basis. There's no issue with other signals here. Stefan
