On 12/11/2010 17:25, Donn Cave wrote:
Quoth Simon Marlow<marlo...@gmail.com>,
...
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?
I don't know - maybe it wouldn't be a problem. But we'd have to measure
things to make sure the extra thread wasn't impacting performance
somehow (e.g. by confusing the OS scheduler).
Quoth Brian Sullivan<b...@serpentine.com>,
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.
Right - making a system call for every safe foreign call and
return/callback probalby would make a difference.
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.
Yes, we still don't know what the problem is there.
Cheers,
Simon
> 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, d...@avvanta.com
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
