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
Attachment:
pgpBzaqwBE5lQ.pgp
Description: PGP signature