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.
