Fix signal handler

[Marc Lehmann]

On Mon, Sep 24, 2012 at 12:00:23PM +0200, SF Markus Elfring <elfring at users.sourceforge.net> 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
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\