signal handling

[rlonstein via Digitalmars-d-learn]

On Saturday, 7 February 2015 at 18:30:00 UTC, Danny wrote:
     [snip]
> Seems to work fine so far. Not sure whether it's safe to 
> raise() inside a signal handler. Calling raise() without 
> reinstalling the old signal handler is a very bad idea, I
     [snip]

I'm not sure that it's really safe to call raise in the handler.
Even C printf() is potentially unsafe leading to recommendations
to use only re-entrant functions. I would not expect raise() to
be safe (ex. never allocates memory or calls gc somewhere down
the line).

      [snip]
> Yeah,I don't think that EINTR and flag-checking is even safe. 
> What if you check the flag (and see nothing happened) and then 
> go back to the loop and block (in read() or whatever), and 
> right after the flag checking, unbeknowst to you the signal 
> handler sets the flag, returns, and only then you block in 
> read()? You'd block forever.

Yes, pretty much.

> Do you know signalfd() ?

Yes, and I'm looking at using it.

> I know how it is with external libaries, they always block at 
> the silliest of times. But I've had one (OKAPI) which gave me 
> the FD back, so I could select() on a bunch FDs in my mainloop. 
> In that case, signalfd() was nice since it showed up as a 
> normal "read ready" in select(), i.e. as a normal "event 
> source". Might be worth a try in your case?
      [snip]
>> so I'm thinking now of leveraging std.signals but I'm not sure 
>> that will be reliable.
>
> Hmm, I don't know that one yet.

Again, probably not safe in sigaction, but using D's 
slots/signals to
communicate that a posix signal has been received and must be
handled. Along with signalfd(), I expect it will let me trigger 
object destruction.