<br><br><div class="gmail_quote">On Fri, Mar 18, 2011 at 3:33 PM, Rolf Bjarne Kvinge <span dir="ltr">&lt;<a href="mailto:rolflists@ya.com">rolflists@ya.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<div class="im"><br></div>
<br>
There is a slight problem now which I just found out: SIGCHLD isn&#39;t 100%<br>
reliable. If I start 100 threads, each of them spawning a process, I usually<br>
get 98-99 signals (unless I run in gdb, in which case I get the same number<br>
of signals, but info-&gt;si_pid is duplicated in many of them...). This means<br>
that only waiting for the reported pid will quite often lead to a zombie<br>
process in my (pathological) test case.<br>
<br>
Attaching revised patch (which is identical to the one in my response to<br>
Rodrigo).<br><br>
</blockquote></div><br><div>Patch looks good except for the missing cleanup on shutdown. The way is to</div><div>hook it up on _wapi_cleanup.</div><div><br></div><div>Signal delivery is never reliable. You patch will probably behave even worse</div>
<div>on osx which doesn&#39;t implement posix real time extensions.</div><div><br></div><div>The worst part is that to do this reliably, one can only depend on OS specific</div><div>features.</div><div><br></div><div>On linux use signalfd with a thread doing a blocking read on it. On OSX you</div>
<div>need to use mach primitives. Other posix-based systems with suck with the</div><div>signal version until patches are submitted.</div><div><br></div><div><br></div><div><br></div>