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

[Jamie Lokier]

Anthony Liguori wrote:
> In KVM, we do use the signal number to determine action.  We could use 
> globals but since we're multi-threaded, that gets pretty nasty.  The 
> same would apply to a threaded QEMU.

Often one pipe per select-caller is enough, with global state to
distinguish events.  For signalfd() emulation, that's an array of

    sig_atomic_t signal_was_hit[NSIG];

(Or just `char' - in pthreads that should be safe to write, right?
One bit is enough storage, but not thread safe.)

However, if you depend on the signal number _combined_ with which
thread receives the signal - then you're in trouble.

pthread_self() should not be called from a signal handler; it's safety
is not portable.  Thread-local storage (__thread int x) is not
portable and might not be signal safe either.  All you've got left is
gettid(), and that's not portable either.

"signalfd helper thread writing to pipe" wouldn't solve that either.
You'd need one _per_ thread that would have called signalfd() (if you
had it) - in order to distinguish recipients.  But that helper's
handler can't tell which thread it is, and therefore which pipe to write to!

But you did say you're using signalfd().  And signalfd() doesn't
distinguish thread recipients (I'm surprised it doesn't).  That whole
meander was just an interesting but irrelevant puzzle.

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,
just call aio_suspend() in the helper thread.  Then you can just
deliver the AIO completion result to the relevant data structure or
even move it off the waiting queue (pthread_mutex_lock is your
friend), then wake the main waiting thread with byte written to its
pipe.

-- Jamie