Quoth Simon Marlow
Is there anything that we could do in GHC to improve the situation? I suppose we could have a dedicated OS thread who's job it was to sit around and run the signal handler every Nth of a second.
Since the -threaded RTS automatically spawns a couple of extra
OS threads anyway, what's one more?
Quoth Brian Sullivan
or masking out RTS signals before calling potentially blocking foreign code (which is all my hack does)
And unmasking on re-entry via callback, I suppose.
It's clear that a large number of C programmers know nothing about restarting system calls, and authors writing FFI code typically can't do anything about that except make sure those system calls don't get interrupted in the first place.
Note that one of the reported victims was "cabal", where I think it was a getContents that aborted with EINTR, on OpenSolaris. I have no idea what was going on there. Nor do I have any idea why my platform libraries are vulnerable to this signal - maybe it's just the usual system call, but I'm not on UNIX. In the present case, ncurses is probably as old as some of the parties to this discussion, and you'd have to wonder if after all this time it doesn't restart its select() on EINTR, if it isn't because that's actually how they want it to work! I'm not going to defend that proposition, but you're right, very low odds that the external world will be fixed to support timer signals. The SIGVTALRM fix solves the problem of an application that uses SIGALRM in its own timer. Donn Cave, donn@avvanta.com