Thanks, Kovid! <div><div>I had no idea multiprocessing uses fork(); this explains everything. It also seems there is no way to get rid of the copied QApplication after forking.</div><div>There is a patch to allow forkless-multiprocessing on unix, but I think it might be for python 3 only.</div>

<div><br></div><div><div class="gmail_quote">On Mon, Jun 11, 2012 at 1:15 PM, Kovid Goyal <span dir="ltr"><<a href="mailto:kovid@kovidgoyal.net" target="_blank">kovid@kovidgoyal.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The one really useful thing in the multiprocessing module is the<br>
Listener and Client classes that allow you to establish easy<br>
communication between your parent and child process. Though even there,<br>
the implementation in multiprocessing is not EINTR safe so you have to<br>
wrap calls to accept(), read(), write() in a wrapper that deals with<br>
EINTR.<br></blockquote><div><br></div><div>I agree with you about the multiprocessing package--I really only use it for the ease of passing python objects between processes. (I use multiprocessing.Pipe(), which I believe uses the Listener/Client system you mentioned). I'll definitely try using this with subprocess instead. Thanks for the EINTR warning; I'm sure that would have taken another hour or two for me to work out :)</div>

<div><br></div><div>Luke</div><div><br></div></div></div></div>