Ian Jackson wrote:
In my signalfd patch, we block SIGUSR2 all the time so it shouldn't be affected by this "bug". We use sigwait or signalfd to receive the signal.Jamie Lokier writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals."):A quick read of Glibc 2.3.1 source says its AIO code does not change the signal mask when it creates an AIO handling thread.Thanks for investigating that.(This might be a Glibc bug - threads you don't know about shouldn't be receiving your signals, should they?)Yes, it's a bug. (I wonder why my test program didn't expose it.)That means if it wasn't masked when you issued the first AIO request, it won't be masked in that thread.In practice since we use aio this probably means we can't rely on signal blocking except for signals which qemu keeps blocked `nearly all' the time. So pipe-to-self in the signal handler is the way to go.
Regards, Anthony Liguori _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [Xen-devel] [PATCH] xc_save: ignore the first suspend event channel notification , Brendan Cully |
|---|---|
| Next by Date: | Re: [Xen-devel] [PATCH] xc_save: ignore the first suspend event channel notification , Keir Fraser |
| Previous by Thread: | Re: [Xen-devel] 2.6.27-rc4 pvops domU on Xen 3.3 Kernel panic , Ingo Molnar |
| Next by Thread: | [Xen-devel] [PATCH 0 of 7] x86: lay groundwork for Xen domain 0 support , Jeremy Fitzhardinge |
| Indexes: | [Date] [Thread] [Top] [All Lists] |