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.
