On Fri, Mar 23, 2012 at 7:51 AM, Frank Lahm <f...@netafp.com> wrote: > Hi, > > I've very recently added libevent to Netatalk, using it for a new service > controller process which is responsible for starting and restarting other > daemons (for now). There I use the signal handling facility of libevent for > handling signals. > > Thanks for libevent, I love it! > > Now it seems at least in signal event callback, that the callback function > can be interrrupted from the same signal it is the handler for.
Yes, this is so. The callback is not called from within the signal handler, but is called from the event loop. All the signal handler does is to write a single byte on a pipe, so that the main loop can notice it and schedule the signal handler again. This lets you call arbitrary functions from the signal callback, whereas the functions you could call from a signal handler are pretty severely restricted. > I noticed > this because in a SIGCHLD handler I added a sleep(5) for debugging purposes > and in a strace I noticed that the sleep got interrupted by another SIGCHLD. > Afaict there's now way in libevent to mimic POSIX signal function semantics > of using a sigmask for atomically blocking signals while the callback is > running, is there? Not really. If there's a really good reason to do this[*], a patch might make sense. [*] I get why you want to block signals from within signal handlers, but I think most of those reasons don't apply --at least, not in a straightforward way-- for blocking signal handlers from within signal event callbacks. > Thanks! > -f > *********************************************************************** > To unsubscribe, send an e-mail to majord...@freehaven.net with > unsubscribe libevent-users in the body. *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
