multiprocessing deadlock

Brian Quinlan brian at
Sat Oct 24 11:23:51 CEST 2009

On 24 Oct 2009, at 19:49, Gabriel Genellina wrote:

> En Sat, 24 Oct 2009 02:48:38 -0300, Brian Quinlan  
> <brian at> escribió:
>> On 24 Oct 2009, at 14:10, Gabriel Genellina wrote:
>>> En Thu, 22 Oct 2009 23:18:32 -0300, Brian Quinlan <brian at 
>>> > escribió:
>>> I don't like a few things in the code:
>> I'm actually not looking for workarounds. I want to know if this is  
>> a multiprocessing bug or if I am misunderstanding the  
>> multiprocessing docs somehow and my demonstrated usage pattern is  
>> somehow incorrect.
> Those aren't really workarounds, but things to consider when trying  
> to narrow down what's causing the problem. The example is rather  
> long as it is, and it's hard to tell what's wrong since there are  
> many places thay might fail.

I agree that the multiprocessing implementation is complex is there  
are a lot of spinning wheels. At this point, since no one has pointed  
out how I am misusing the module, I think that I'll just file a bug.

> The busy wait might be relevant, or not; having a thousand zombie  
> processes might be relevant, or not.

According to the docs:

"""On Unix when a process finishes but has not been joined it becomes  
a zombie. There should never be very many because each time a new  
process starts (or active_children() is called) all completed  
processes which have not yet been joined will be joined. Also calling  
a finished process’s Process.is_alive() will join the process.  Even  
so it is probably good practice to explicitly join all the processes  
that you start."""

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Python-list mailing list