Odd behavior of ncurses with -threaded

[Donn Cave]

Quoth Simon Hengel <simon.hengel at wiktory.org>,
...
> This works just fine if I do not use the threaded RTS, say:
>
>     ghc --make -lcurses Main.hs
>
> However, with
>
>     ghc --make -threaded -lcurses Main.hs

I bet, if you switch off the barrage of thread scheduling SIGALRMs,
  +RTS -V0 -RTS , it will work like it's supposed to.

A very casual scrutiny of an ncurses source I have at hand shows
no EINTR handling on select() in lib_getch.c.  That could be the
problem, or something like it - select() is interrupted by GHC's
SIGALRM, aborting the timeout.  Or they could both be using SIGALRM, 
and GHC's signal is mistaken for the application library's, but
I don't see any sign of that and select() is a more obvious way
to do the timeout anyway.

> it prints -1 immediately without awaiting the 3 seconds.
>
> Is that considered a bug? Should I open a ticket?
>
> ghc:     6.12.1
> linux:   2.6.32
> ncurses: 5.7

Someone probably should.  It's tempting to conclude that the bug
is in ncurses, and perhaps it is, and maybe there's nothing to be
done about it anyway, but a language runtime that's spewing SIGALRMs
is going to crash into this kind of thing a lot.  I could comment a
couple of other cases to the ticket that I've seen here or on Haskell-cafe.

	Donn Cave, donn at avvanta.com