Foreign calls and periodic alarm signals

[Simon Marlow]

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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>