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...