[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] Atomically block signals in signal event callbacks



On Fri, Mar 23, 2012 at 7:51 AM, Frank Lahm <fl@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.