Foreign calls and periodic alarm signals
marlowsd at gmail.com
Thu Sep 3 22:12:07 UTC 2015
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
> I received a report on this rather strange bug in 'directory':
> 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 , 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.
> : https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs