On Mon, Sep 24, 2012 at 12:00:23PM +0200, SF Markus Elfring <[email protected]> wrote: > I find that the information "ev_feed_signal ... safe to call this function > ..., > including signal handlers or random threads." is not satisfied by the current > implementation at the moment. > Reasons: > 1. A shared array is used there.
And why would that not be safe? > 2. Would it eventually need to be protected by a mutex (from the > multi-threading > perspective)? Using a mutex in a signal handler is neither conforming nor working in practise, so far worse than the current approach. > > Libev currently should be async signal safe - > > I try to point out that it is not in a portable way at one place. So far, you failed in your attempt though. By your first mail, I suspect your definition of "portable" means "strictly conforming C99 program" or something very similar. Libev cannot ever be strictly conforming - it's good enough when it works on existing platforms. To show an actual problem it is not enough to show that libev isn't strictly conforming - libev isn't bound by C99 (and cannot be so ever), it's in the same class as basically every other existing program. > Are the following statements really so robust (and therefore without race > conditions) for the discussed use case as you might expect? Nothing suggests otherwise. > > 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. > > Would you like to consider any secure coding recommendations once again? Sure, but what of them? > I suggest to reuse this technique for a replacement of a global array in a > signal handler. > http://cr.yp.to/docs/selfpipe.html As I explained before, this url does not list any such technique, and libev already uses that technique. Can you please re-read my original reply, I think it was quite clear. I don't think you understand the page you reference, or what problem it solves, at all. I pointed out what the self-pipe trick solves in my previous mail as well. > Will any lock-free approaches become feasible for comparison and selection by > a > build configuration? Libev's algorithm is already lock-free (and has to be) - what do you want to compare it with? -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [email protected] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
