On Fri, Feb 20, 2015 at 7:58 PM, Rob Leslie <rob@mars.org> wrote:

My experience with forkProcess so far is that sometimes it works brilliantly, and other times it just deadlocks. I’m at a loss to understand what the problem is, but the deadlock seems to occur before the new process gets any control -- certainly before it has started to access any of the shared state.

I'd be using strace / truss / dtruss / platform equivalent to see what's going on in that case.

I’m aware of the giant warning in the forkProcess documentation, but I’m not sure if or how it could explain the behavior I’m seeing. Has anyone else used forkProcess successfully?

xmonad uses it extensively with no problems except an oddity on FreeBSD that appears to be some nonportable behavior inside GHC's I/O manager. (The person who ran into that was asked to submit a GHC bug report.) That said, it doesn't do any significant processing in the child process; the most common use is a double-fork with the grandchild doing executeFile. It is conceivable that the I/O manager is not handling some use cases other than that one properly; since most uses of forkProcess are followed by executeFile, it's entirely possible that some bug has crept in that only shows up in the few cases where that isn't done.

It’s possible too that I’m running into something related to the way I’m setting up a pipe to receive messages from the forked process. Here is what I’m doing:

The basic pipe handling looks correct to me, for what it's worth.

brandon s allbery kf8nh sine nomine associates

allbery.b@gmail.com ballbery@sinenomine.net

unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net