On Sun, Sep 23, 2012 at 07:40:59PM +0200, SF Markus Elfring <elfr...@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 --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
