<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 12:15 AM, Mark Lentczner <span dir="ltr"><<a href="mailto:mark.lentczner@gmail.com" target="_blank">mark.lentczner@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Sorry to be reviving this thread so long after.... but I seem to be running into similar issues as Michael S. did at the start.<div>
<br></div><div>In short, I'm using forkProcess with the threaded RTS, and see occasional hangs:</div>
<div class="gmail_extra"><ul><li>I see these only on Linux. On Mac OS X, I never do.</li></ul></div></div></blockquote><div style>Previous versions of the linux pthreads library didn't hold any shared resources in locks, so pthread_mutex_destroy could not hang. Now Linux is much improved, and thus it hangs (see pthread_mutex_destroy man page) ;-).</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<ul><li>I'm using GHC 7.4.2</li><li>I noticed the warning in the doc for forkProcess, but assumed I was safe, as I wasn't holding any shared resources at the time of the fork, and no shared resources in the program are used in the child.</li>
<li>WIth gdb, I've traced the hang to here in the run-time: <font face="courier new, monospace">forkProcess > discardTasksExcept > freeTask > closeMutex(&task->lock) > pthread_mutex_destroy</font></li>
</ul>The discussion in this thread leaves me with these questions:</div><div class="gmail_extra"><ul><li>Is there reason to think the situation has gotten better in 7.6 and later?</li><li>Isn't the only reason <b>System.Process</b> is safer because it does an immediate exec in the child? Alas, I really want to just <font face="courier new, monospace">fork()</font> sometimes.</li>
</ul></div></div></blockquote><div style>If you immediately do exec() in the child, you can use vfork() which blocks the parent. This serializes the actions and makes this whole mess smooth and consistent.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><ul>
<li>Is it really true that even if my program has no shared resources with the child, that the IO subsystem and FFI system do anyway? Surely the RTS would take care of doing the right thing with those, no?</li></ul></div>
</div></blockquote><div style>It looks like the RTS is trying to do a lot of things to control all the Haskell threads etc. But I don't think it waits for FFI-land threads before commencing a fork(), so that's why I'm guessing that some interaction between threads using FFI and fork() could be the issue.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><ul><li>There should be no concern with <font face="courier new, monospace">exec</font> w.r.t. library invariants since <span style="font-family:'courier new',monospace">exec</span> is wholesale replacement - all the libraries will reinitialize. Is there a problem here I'm missing?</li>
</ul></div></div></blockquote><div style>I think that's right. vfork() + exec() can be serialized and deterministic thus is a lot easier to reason about.</div><div style><br></div><div style>Alexander</div></div></div>
</div>