quoth Phil Ruffwind
The reporter found that using 'foreign import safe' mitigates the issue. What I'm curious mainly is that: is something that the GHC runtime guarantees -- is using 'foreign import safe' assured to turn off the periodic signals for that thread?
Can't answer that, but I suppose I would recommend it anyway, because unsafe foreign calls cause other OS threads to block in the runtime. So any real I/O might as well be "safe". To reliably avoid these signals, you can turn them off with the -V0 runtime flag. For a UNIX shell example, GHCRTS=-V0 your-command-here. You have to build it with the -rtsopts flag. I suppose there are some consequences to doing that, but I've never noticed anything and haven't heard of anyone else noticing anything.
I'm also concerned whether there are other foreign functions out in the wild that could suffer the same bug, but remain hidden because they normally complete before the next alarm signal.
Sure are, though I don't know of any that have been identified so directly as yours. I mean it sounds like you know where and how it's breaking. Usually we just know something's dying on an interrupt and then think to try turning off the signal barrage. It's interesting that you're getting a stall instead, due to an EINTR loop. Donn