Odd behavior of ncurses with -threaded

[Donn Cave]

Quoth Simon Marlow <marlowsd at 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?

Quoth Brian Sullivan <bos at 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.

> 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 at avvanta.com