On Wed, Jun 13, 2012 at 7:53 AM, Kovid Goyal wrote:
> On Mon, Jun 11, 2012 at 01:59:35PM -0400, Luke Campagnola wrote:
>> 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
On Mon, Jun 11, 2012 at 01:59:35PM -0400, Luke Campagnola wrote:
> 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).
Luke Campagnola wrote:
> 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 subpr
Thanks, Kovid!
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.
There is a patch to allow forkless-multiprocessing on unix, but I think it
might be for python 3 only.
On Mon, Jun 11, 2012 at 1:15
Don't use multiprocessing. multiprocessing is not thread safe, on unix
it uses fork() without exec() which means that it inherits *everything*
from the parent process including locks (which are in an invalid state
in the child process), file handles, global objects like QApplication
and so on. Just
Howdy,
I am trying to use multiprocessing in a PyQt application to spawn an extra
process with its own GUI. The problem I am running into is that the child
process seems to be instantiated with a broken QApplication instance that
causes the child to crash. If I understand multiprocessing correctly
