Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals.

[Jamie Lokier]

Ian Jackson wrote:
> > > If you use aio, glibc has a tendency to emulate it with thread(s).
> > > The helper thread I was referring to in my commit message is the
> > > glibc-created helper thread.  glibc appears (in strace) to do IO in
> > > this thread and then raises the signal you asked for (SIGUSR2 in
> > > qemu's case).
> > 
> > That observation implies Anthony's helper thread will not always
> > receive the SIGUSR2 signals - Glibc's thread may receive them instead.
> 
> Yes.  Err, I'm not sure what effect that will have in Anthony's patch
> but it probably wouldn't be good.
> 
> As I say I haven't managed to reproduce this other than in a full
> qemu-dm tree (from qemu-xen).
> 
> So it may be that it is because of something I did or something the
> qemu-xen code does - although it seems hard to imagine how it could
> break the signal mask in the helper thread given that that thread runs
> entirely glibc code, except when a signal is being delivered (and of
> course the signal mask is saved and restored for signal delivery).

It's not your fault.

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.

(This might be a Glibc bug - threads you don't know about shouldn't be
receiving your signals, should they?)

That means if it wasn't masked when you issued the first AIO request,
it won't be masked in that thread.

It's quite annoying that POSIX threads doesn't provide any way to say
"mask this signal in all other threads", which you often want to do
from a library.

-- Jamie