Quoth Simon Hengel
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@avvanta.com