libev signal mask and thread

Konstantin Osipov kostja at
Sat Apr 28 20:56:27 CEST 2012

* Marc Lehmann <schmorp at> [12/04/28 21:48]:
> > Unless I block signals in all threads but the main, the signal
> > sent to a process can be delivered to any thread, and thus libev
> > won't see it.
> If this is the case, then this is another issue, independent of
> libev. Libev does not care which thread handles the signal, it only
> cares about not receiving a signal while it manipulates it's signal data
> structures.

I don't think it's going to be the case if signalfd is used.
But generally, if I remember my Butenhof (*) correctly, that's what
can happen according to SUSv2/POSIX.

> > I was wondering what would be a canonical way to do it? 
> Well, your problem seems to come from another component, not libev. Libev
> is fine with either way.
> > A simple approach is to temporarily block signals by calling
> > pthread_sigmask(), then call pthread_create(), make sure the created
> > thread inherits the signal mask, and then unblock signals
> > again and let libev handle them.
> Blocking all signals in threads that are normally not interested in
> handling them is good programming practise, and the way you describe is
> the canonical way to do that (i wish glib would do that :).
> It's not required for libev, though - libev doesn't know anything about
> threads, and does not care about which thread handles the signal.


-- - an efficient, extensible in-memory data store

More information about the libev mailing list