Linux signal handling - notifying a condition variable

[Adam D. Ruppe]

On Thursday, 15 March 2018 at 17:30:50 UTC, Jim King wrote:
> The problem with that is that it requires a busy loop to detect 
> it.

well, what's your thread doing? In the case I used this pattern, 
it was blocking on a call to select() anyway, so when it returned 
with EINTR, that was a good opportunity to check the flag before 
waiting for the next event.

But of course that isn't always going to be the case...

> I think it would be possible for someone to catch this and make 
> sure it does not throw, but the "@nogc" part of it seems a bit 
> more involved.  Condition variables (and mutexes) are supposed 
> to be usable from a signal handler.

Yeah, I think this is just an oversight. See, the throw on error 
previously didn't work well with @nogc (you could do it, but the 
catcher would have to free the exception object which most code 
wouldn't do) and the newest dmd version changes that.

But the library developer would still have to verify it and add 
the @nogc annotation themselves.

Of course, it is still throwing, but you can catch in the signal 
handler to make it nothrow at that point.


So I'd say probably file a bug and/or open a PR yourself to add 
the @nogc annotation to those methods and it'll probably work 
next release.