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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Jamie Lokier writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle 
terminating signals."):
> Leading to: why would (real) signals being used to collect AIO events
> anyway, if you don't have signalfd()?  If you've got a helper thread,

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).

In some of my tests with qemu that SIGUSR2 was then immediately
delivered on the helper thread even though the main program had it
blocked.  I saw this in strace in a real qemu instance but I wasn't
able to reproduce it in a trivial test program.  The result is that we
lose the race that sigwait() is supposed to avoid.  Hence my
replacement of sigwait with the self-pipe trick.

This is not to be confused with Anthony Ligouri's helper thread, which
is doing the same job as my SIGUSR2 handler.  In Anthony's setup there
will be two helper threads (assuming no signalfd and no kernel aio):
one invented by glibc to emulate aio, and one invented by Anthony to
emulate signalfd.  glibc will do the aio in its helper thread, raise
SIGUSR2, which will wake up Anthony's thread, which will write to the
pipe and thus wake up the main program.

Ah, plumbing.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel