Fix signal handler

Marc Lehmann schmorp at
Sun Sep 23 23:10:01 CEST 2012

On Sun, Sep 23, 2012 at 07:40:59PM +0200, SF Markus Elfring <elfring at> wrote:
> The expectations from an information in the documentation like the following can
> not be completely satisfied at the moment.

Can you elaborate on why not?

> > As far as we know, the current method is already safe and robust, and
> > evidence to the contrary would be appreciated, but so far, none is known.
> I imagine that the affected function could be made async-signal-safe if all
> received signal numbers will be written to a dedicated pipe.

The URL you refer to does describe exactly the technique that libev
currently implements (and has nothing to do with being async signal safe,
it's about avoiding a race with select and poll that could also be avoided
by using pselect or ppoll).

What you describe in this e-mail is a different technique that is not
practical as it can lead to deadlock or lost signals under load (think of
what happens when the pipe is full).

Libev currently should be async signal safe - again, if you have any
actual evidence to the contrary, we'd be interested to hear about them. If
your suggestions are purely theoretical, I would suggest studying libev
first to see what it actually dies - if you have any specific questions,
feel free to ask.

> > If you know of a method that allows us to do this in a practical but still
> > strictly c99 conforming way that would be cool, but I will not hold my breath :)
> Would the pipe approach be acceptable for you?

No, regarding your technique, neither deadlocks nor lost signals are
acceptable. Regarding the self-pipe trick, that's exactly what libev
currently implements (except it uses an eventfd instead of a pipe if

> Does it make sense to choose such implementation details also by a build
> configuration?

I can't think of any reason for that - I don't see an alternative to the
current implementation using the self-pipe trick.

Future versions of libev will likely implement details differently
(e.g. to detect whether the signal was received before or after a
fork), but even then I don't see why one would chose between different

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list