<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Oct 15, 2012 at 6:30 PM, Joey Hess <span dir="ltr"><<a href="mailto:joey@kitenet.net" target="_blank">joey@kitenet.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Michael Snoyman wrote:<br>
> I think I have a misunderstanding of how forkProcess should be working.<br>
> Ultimately this relates to some bugs in the development version of keter, but<br>
> I've found some behavior in a simple test program which I wouldn't have<br>
> expected either, which may or may not be related.<br>
><br>
> With the program at the end of this email, I would expect that, once per<br>
> second, I would get a message printed from each forkIO'd green thread, the<br>
> forked process, and the master process. And if I spawn 8 or less child threads<br>
> that's precisely what happens. However, as soon as I up that number to 9, the<br>
> child process is never run. The process is, however, created, as can be<br>
> confirmed by looking at the process table.<br>
><br>
> This only occurs when using the multithreaded runtime. In other words,<br>
> compiling with "ghc --make test.hs" seems to always produce the expected<br>
> output, whereas "ghc --make -threaded test.hs" causes the behavior described<br>
> above. Having looked through the code for the process package a bit, my initial<br>
> guess is that this is being caused by a signal being sent to the child process,<br>
> but I'm not familiar enough with the inner workings to confirm or disprove this<br>
> guess.<br>
><br>
> If anyone has any ideas on this, I'd appreciate it.<br>
<br>
</div>While I'm not reproducing that behavior here with your test case and<br>
7.4.1, I recently converted a large program to use -threaded (because I<br>
needed to use yesod in it, actually :), and had large quantities of pain<br>
involving forkProcess. It seemed to come down to this easily overlooked<br>
note in the docs:<br>
<br>
forkProcess comes with a giant warning: since any other running threads<br>
are not copied into the child process, it's easy to go wrong: e.g. by<br>
accessing some shared resource that was held by another thread in the<br>
parent.<br>
<br>
In my experience, forkProcess often behaves incomprehensibly (to me)<br>
with -threaded, typically resulting in a forked process hanging, and<br>
quite often only some small percentage of the time, which makes it<br>
really hard to track down and try to diagnose what thunk might not be<br>
getting forced until after the fork, or whatever.<br>
<br>
I did some analysis and produced a test case for problems caused by<br>
use of forkProcess in parts of MissingH, here:<br>
<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681621" target="_blank">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681621</a><br>
<br>
My understanding is that System.Process avoids these problems by doing<br>
all the setup around forking a command in C code. I've banished<br>
forkProcess from my code base entirely, except for a double fork I need<br>
to daemonize, and I don't even trust that call. :/<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Thanks for the input everyone!</div><div><br></div><div>Michael</div></div></div>