Richard Oudkerk added the comment:
This is really a documentation issue. The doc fix for #18277 covers this.
--
components: +Library (Lib) -Extension Modules
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Richard Oudkerk added the comment:
On 15/05/2013 11:33pm, Andre Dias wrote:
> But the example program has no races, no threads, nothing.
> empty() is returning TRUE even though qsize() is >0 (which actually is)
> And it happens almost every time I run that small example.
> I had read the module d
Andre Dias added the comment:
RIchard,
But the example program has no races, no threads, nothing.
empty() is returning TRUE even though qsize() is >0 (which actually is)
And it happens almost every time I run that small example.
I had read the module doc, and I know its an unreliable method, but
Richard Oudkerk added the comment:
On 15/05/2013 10:25pm, Andre Dias wrote:
> But qsize() is working. what is not working is empty()
empty() returns False when there is data in the underlying pipe. But
the data does not enter the pipe until a background thread has written
it to the pipe. Thi
Andre Dias added the comment:
But qsize() is working. what is not working is empty()
2013/5/15 Richard Oudkerk
>
> Richard Oudkerk added the comment:
>
> >From the docs:
>
> qsize()
> Return the approximate size of the queue. Because of
> multithreading/multiprocessing semantics, this
Richard Oudkerk added the comment:
>From the docs:
qsize()
Return the approximate size of the queue. Because of
multithreading/multiprocessing semantics, this number
is not reliable.
Adding a short sleep before calling qsize() and empty() should make things
appear to work.
But re
New submission from Andre Dias:
The problem is that Queue.empty() is True even if Queue.qsize()>0!
#!/usr/bin/python
from multiprocessing import Queue
numbers=Queue()
for i in range (0,10):
numbers.put(i)
if numbers.qsize()>0 and numbers.empty():
print "BUG?!"
--
components:
