SIGVTALRM and Unbound threads
Howdy, I've banged into this issue of FFI errors stemming from a C library improperly handling system call interrupts caused by the SIGVTALRM/SIGALRMs emitted by the Haskell runtime. Usually the 'proper' solution is to fix the C library—easier said than done for most C quagmires. The most popular workaround, described by Bryan O'Sullivan[1] and several others, is to block the culprit signals from reaching the FFI call. I found another workaround using unbound threads, and it seems to work generally for this problem. However, I'm not satisfied with my understanding about *why* it works given what I know about FFI, bound vs unbound threads, and sys calls. As the simplest example, compiled with the threaded runtime (and neglecting imports): main = void $ sleep 10 will be interrupted, whereas main = void $ runInUnboundThread $ sleep 10 will complete its 10 second sleep. How does running the FFI call on an unbound thread block SIGVTALRM or otherwise avoid the interrupt? My understanding is that these signals *should* reach the FFI process, since they're on the same OS thread the timers were set. Is there any danger to consider before saying that this is a viable workaround? Kindly, Lane [1]: http://www.serpentine.com/blog/2010/09/04/dealing-with-fragile-c-libraries-e...
On 14-09-25 03:55 PM, Lane Seppala wrote:
As the simplest example, compiled with the threaded runtime (and neglecting imports):
main = void $ sleep 10
will be interrupted, whereas
main = void $ runInUnboundThread $ sleep 10
will complete its 10 second sleep.
Before you commit to your understanding, consider one more experiment that changes everything: main = void $ runInUnboundThread (runInBoundThread $ sleep 10) Also, consider hitting CTRL-C (or sending SIGINT any way), see what does not happen. Do you want this behaviour?
Hmm. Using your experiment, I didn't see any differing behavior from my
original example (both GHC 7.6.3 and 7.8.3). What should I have expected?
That being said, I hadn't tried sending SIGINT to the running process as
you suggested. Thanks for this idea. Both for my example and yours, it
takes two SIGINTs to kill the process. Interesting and surely not desired
behavior, but I might not understand what the implications are.
I ran each program with strace and sent SIGINTs to it while running. I
found it interesting that each program had paused emitting SIGVTALRMs until
I sent the first SIGINT, which then it resumed without interrupting the
sleep. The second SIGINT exited the process.
I'm even more curious &/ confused about the interaction of unbounded
threads and signals now, or if there's any interaction at all. The pausing
of the SIGVTALTRMs mentioned above makes me wonder whether it's the
unbounded thread or some auxiliary mechanism that helps prevent interrupts.
I'd love to have a deeper understanding of this interworking between
signals and unbounded threads. My own web scouring hasn't turned up
anything, but I'd be happy to be pointed somewhere.
Kindly,
Lane
On Thu, Sep 25, 2014 at 3:59 PM, Albert Y. C. Lai
On 14-09-25 03:55 PM, Lane Seppala wrote:
As the simplest example, compiled with the threaded runtime (and neglecting imports):
main = void $ sleep 10
will be interrupted, whereas
main = void $ runInUnboundThread $ sleep 10
will complete its 10 second sleep.
Before you commit to your understanding, consider one more experiment that changes everything:
main = void $ runInUnboundThread (runInBoundThread $ sleep 10)
Also, consider hitting CTRL-C (or sending SIGINT any way), see what does not happen. Do you want this behaviour? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 14-09-25 06:51 PM, Lane Seppala wrote:
Hmm. Using your experiment, I didn't see any differing behavior from my original example (both GHC 7.6.3 and 7.8.3). What should I have expected?
You should revise your theory. Hypothesis: C sleep in a bound thread quits prematurely. Experiment: Put C sleep in a bound thread, just not main's. Result: this C sleep in this bound thread does not quit prematurely. What does this tell us about the hypothesis? I'm doing the scientific method.
participants (2)
-
Albert Y. C. Lai -
Lane Seppala