<br><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 21, 2012 at 11:34 AM, Mike Meyer <span dir="ltr"><<a href="mailto:mwm@mired.org" target="_blank">mwm@mired.org</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">On Wed, Nov 21, 2012 at 9:12 AM, Sturla Molden <<a href="mailto:sturla@molden.no">sturla@molden.no</a>> wrote:<br>
> See this:<br>
><br>
> <a href="http://mail.scipy.org/pipermail/numpy-discussion/2012-August/063593.html" target="_blank">http://mail.scipy.org/pipermail/numpy-discussion/2012-August/063593.html</a><br>
><br>
</div>> According to Apple engineers:<br>
<div class="im">><br>
> """<br>
> For API outside of POSIX, including GCD and technologies like<br>
> Accelerate, we do not support usage on both sides of a fork(). For<br>
> this reason among others, use of fork() without exec is discouraged in<br>
> general in processes that use layers above POSIX.<br>
> """<br>
><br>
> Multiprocessing on OSX calls os.fork, but not os.exec.<br>
><br>
> Thus, is multiprocessing errorneously implemented on Mac? Forking without<br>
> calling exec means that only APIs inside POSIX can be used by the child<br>
> process.<br></div></blockquote><div><br></div><div>I don't care how this is read or what the default behavior is. All I want is for someone who cares about multiprocessing actually working well for people to implement optional support for *not* using os.fork() on posixish systems.  ie: port an equivalent of the windows stuff over.</div>

<div><br></div><div>I don't use multiprocessing so I've never looked into adding it.  It shouldn't be difficult given the legwork has already been done for use on windows.  this is exactly what issue8713 is asking for.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Does multiprocessing needs a reimplementation on Mac to behave as it does on<br>
> Windows? (Yes it would cripple it similarly to the crippled multiprocessing<br>
> on Windows.)<br>
<br>
</div>-1.<br></blockquote><div><br></div><div>+10 - though I wouldn't call it a "re" implementation, just a port of the windows stuff.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Mac's make nice Unix desktops (if you like their GUI), and it's not<br>
uncommon to find people writing & testing software on Mac's for<br>
deployment to POSIX servers. Such people using the multiprocessing<br>
module need it to provide proper POSIX behavior.<br></blockquote><div><br></div><div>Those people are delusional, they need to test their software on the OS it is destined to run on. Not on their terminal.</div><div><br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br></div>
In general, these issues are simply a case of needing to be aware of<br>
what your program is doing, and making sure you don't do things that<br>
can cause problems - whether you're using above-the-POSIX Mac APIs, or<br>
POSIX the problematic Posix APIs.  A case might be made that the<br>
multiprocessing module should help with that, by providing a way to<br>
say "I'm doing things that make fork dangerous, please use the<br>
system-appropriate fork+exec call instead."<br></blockquote><div><br></div><div>Yep.  Like I said, I don't personally care what the default is.  I just want support for both options so that people have a way to _not_ shoot themselves in the foot.</div>

<div><br></div><div>-gps</div></div></div>