On 02/09/2015 15:42, Phil Ruffwind wrote:
TL;DR: Does 'foreign import safe' silence the periodic alarm signals?
No it doesn't. Perhaps the fact that a safe FFI call may create another worker thread means that the timer signal has gone to the other thread and didn't interrupt the thread making the statfs64() call. There's pthread_setmask() that could help, but it's pretty difficult to do this in a consistent way because we'd have to pthread_setmask() every thread that runs Haskell code, including calls from outside. I'm not sure yet what the right solution is, but a good start would be to open a ticket. Cheers Simon
I received a report on this rather strange bug in 'directory':
https://github.com/haskell/directory/issues/35#issuecomment-136890912
I've concluded based on the dtruss log that it's caused by the timer signal that the GHC runtime emits. Somewhere inside the guts of 'realpath' on Mac OS X, there is a function that does the moral equivalent of:
while (statfs64(…) && errno == EINTR);
On a slow filesystem like SSHFS, this can cause a permanent hang from the barrage of signals.
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?
I tried reading this article [1], which seems to be the only documentation I could find about this, and it didn't really go into much depth about them. (I also couldn't find any info about how frequently they occur, on which threads they occur, or which specific signal it uses.)
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.
[1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs