Fix signal handler

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


On Sun, Sep 23, 2012 at 07:40:59PM +0200, SF Markus Elfring <elfring at users.sourceforge.net> 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.
> http://cr.yp.to/docs/selfpipe.html

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
available).

> 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
implementations.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list