Charles-François Natali added the comment:
It's a dupe of issue #8426: the Queue isn't full, but the underlying pipe is,
so the feeder thread blocks on the write to the pipe (actually when trying to
acquire the lock protecting the pipe from concurrent access).
Since the children processes join
Erdem U. Altinyurt added the comment:
Firstly I think as you but this is not correct.
Added Q.full() to know if Queue is full or not to the testQ code..
def testQ():
for i in range(1):
mp.Process( None, QueueWorker, None, (i,Q,lock) ).start()
while len(mp.active_children())>=
Jesse Noller added the comment:
multiprocessing.Queue.Put() acts the same as Queue.put() - if the queue is
full, the put call "hangs" until the queue is no longer full. The process will
not exit, as the Queue is full, and it's waiting in put.
This works as designed, unless I'm missing somethi
R. David Murray added the comment:
Crash is for interpreter segfaults, changing to type 'behavior'. Setting stage
to 'test needed' because if this is a valid bug the test will need to be turned
into a unit test.
--
nosy: +jnoller, r.david.murray
priority: -> normal
stage: -> test n
New submission from Erdem U. Altinyurt :
multiprocessing.Queue() blocking program on my computer after adding 1400 entry
(depending addition size).
Tested with 2.6.2 and 2.6.5(compiled from source with gcc 4.4.1)
Using 64 bit OpenSUSE 11.2.
Output is:
---
1398 done
1399 done
--
