[Haskell-cafe] forkProcess, forkIO, and multithreaded runtime
michael at snoyman.com
Tue Oct 16 15:54:31 CEST 2012
On Mon, Oct 15, 2012 at 6:30 PM, Joey Hess <joey at kitenet.net> wrote:
> Michael Snoyman wrote:
> > I think I have a misunderstanding of how forkProcess should be working.
> > Ultimately this relates to some bugs in the development version of
> keter, but
> > I've found some behavior in a simple test program which I wouldn't have
> > expected either, which may or may not be related.
> > With the program at the end of this email, I would expect that, once per
> > second, I would get a message printed from each forkIO'd green thread,
> > forked process, and the master process. And if I spawn 8 or less child
> > that's precisely what happens. However, as soon as I up that number to
> 9, the
> > child process is never run. The process is, however, created, as can be
> > confirmed by looking at the process table.
> > This only occurs when using the multithreaded runtime. In other words,
> > compiling with "ghc --make test.hs" seems to always produce the expected
> > output, whereas "ghc --make -threaded test.hs" causes the behavior
> > above. Having looked through the code for the process package a bit, my
> > guess is that this is being caused by a signal being sent to the child
> > but I'm not familiar enough with the inner workings to confirm or
> disprove this
> > guess.
> > If anyone has any ideas on this, I'd appreciate it.
> While I'm not reproducing that behavior here with your test case and
> 7.4.1, I recently converted a large program to use -threaded (because I
> needed to use yesod in it, actually :), and had large quantities of pain
> involving forkProcess. It seemed to come down to this easily overlooked
> note in the docs:
> forkProcess comes with a giant warning: since any other running threads
> are not copied into the child process, it's easy to go wrong: e.g. by
> accessing some shared resource that was held by another thread in the
> In my experience, forkProcess often behaves incomprehensibly (to me)
> with -threaded, typically resulting in a forked process hanging, and
> quite often only some small percentage of the time, which makes it
> really hard to track down and try to diagnose what thunk might not be
> getting forced until after the fork, or whatever.
> I did some analysis and produced a test case for problems caused by
> use of forkProcess in parts of MissingH, here:
> My understanding is that System.Process avoids these problems by doing
> all the setup around forking a command in C code. I've banished
> forkProcess from my code base entirely, except for a double fork I need
> to daemonize, and I don't even trust that call. :/
Well, I tried switching my code to forking/execing from C in a very similar
manner to the process package, and it seems to work.
Thanks for the input everyone!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe