signal handling and posix threads

[Nick Mathewson]

On Mon, Feb 19, 2007 at 11:01:54PM -0800, coderman wrote:
 [...]
> there are some libevent considerations as well, particularly
> evsignal_*, although i'm also not very familiar with how libevent
> handles signals in a threaded context.

Thanks!

Your patch below looks sane; I've applied it.  Libevent's current
approach seems to rely on calling sigprocmask, though, and that's not
right in a multithreaded program IIRC, since it can (on some threading
implementations) affect the signal masks of other threads besides the
calling thread.  Probably, the right answer is to hack up libevent's
signal.c somehow, to call pthread_sigprocmask rather than sigprocmask
under some circumstances.

(I say 'under some circumstances' since single-threaded applications
using libevent will want to call the regular sigprocmask.)

 [...]
> has this been discussed before in the context of the Tor event loop
> when using pthread?  is anyone more familiar with libevent aware of
> the usual idioms for handling signals within worker pthreads?  (it
> appears at first glance that most signal mgmt in libevent is at a
> process level)

Libevent is pretty heavily based on the idea that you're going to have
one thread that calls all the libevent functions, so it should be okay
to block signals in workers.  I'm pretty sure that
libevent _doesn't_ handles signals right in the presence of some kinds of
threads.  The code calls sigprocmask twice in signal.c, once in
evsignal_recalc and once in evsignal_deliver.  (The rtsig stuff is for
real-time signals, which Tor doesn't use.)  Libevent blocks and
unblocks signals fairly often, so it probably needs to get fixed as
noted above before it will stop unblocking signals that were blocked
within subthreads.

The hard part of fixing libevent here will probably be picking the
right interface to say, "I'm going to be using threads, so please call
pthread_sigprocmask instead of regular sigprocmask()."

yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070220/678feb56/attachment.pgp>