This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: multiprocessing.Queue.get is not getting all the items in the queue
Type: behavior Stage: resolved
Components: Versions: Python 3.4, Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Roberto Martínez, alexei.romanov, davin, r.david.murray, sbt
Priority: normal Keywords:

Created on 2015-03-04 10:15 by Roberto Martínez, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
mpqueuegetwrong.py Roberto Martínez, 2015-03-04 10:15 Example of the wrong behavior. The process should get 100 items but only a few can be retrieved.
Messages (5)
msg237178 - (view) Author: Roberto Martínez (Roberto Martínez) Date: 2015-03-04 10:15
We face yesterday a bug in a project, and after a few hours of investigation we found a bad/not documented behavior in multiprocessing.Queue.

If you put one or more items in a queue and if the items are large, there is a delay between the put is executed and the item is finally available in the queue. This is reasonable because the underlying thread and the pipe, but the problem is not this.

The problem is that Queue.qsize() is reporting the number of items put, Queue.empty() is returning True, and Queue.get() is raising Empty.

So, the only safe method to get all the items is as follows:

while q.qsize():                                                         
    try:                                                                 
        item = q.get_nowait()                                                   
    except Empty:                                                        
        pass

Which is not very nice.

I attach a sample file reproducing the behavior, a single process put 100 elements in a Queue and after that it tries to get all of them, I tested in python 2.7.9 and 3.4 with the same result (seems python3 is a little bit faster and you need to enlarge the items). Also if you wait between get's, the process is able to retrieve all the items.
msg237189 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-03-04 16:04
This is the documented behavior.  "qsize: Return the approximate size of the queue. Note, qsize() > 0 doesn't guarantee that a subsequent get() will not block, nor will qsize() < maxsize guarantee that put() will not block."

It looks like what you want here is get with a timeout, not get_nowait.
msg237204 - (view) Author: Roberto Martínez (Roberto Martínez) Date: 2015-03-04 19:47
I think you misunderstood my explanation. My english is not very good, sorry.

I think that my previously attached file (mpqueuegetwrong.py) shows it better than my words. In this file you can see that I am not calling qsize nor get_nowait, only put and get. And the behavior I am reporting is only related to those methods (and I think it is not documented).
msg237211 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-03-04 20:57
You are calling q.empty when draining the queue.  That has the same documented caution.  Since you are using get in that loop, in that case you *want* to be calling qsize, just like you do when you drain it at the end.
msg237214 - (view) Author: Roberto Martínez (Roberto Martínez) Date: 2015-03-04 21:33
That's not my point.

To my understanding, when you put a item in the queue the item *must* be available to get in the next call. So I think put should block until the item is really in the queue so when you call get it return *always* and not some times (depending on the item size).

If this is not the expected behavior I think it should be warned in the put/get method.
History
Date User Action Args
2022-04-11 14:58:13adminsetgithub: 67770
2015-03-05 17:49:23davinlinkissue20147 superseder
2015-03-04 21:33:34Roberto Martínezsetmessages: + msg237214
2015-03-04 20:57:38r.david.murraysetmessages: + msg237211
2015-03-04 19:47:49Roberto Martínezsetmessages: + msg237204
2015-03-04 16:04:33r.david.murraysetstatus: open -> closed

nosy: + r.david.murray
messages: + msg237189

resolution: not a bug
stage: resolved
2015-03-04 10:57:21berker.peksagsetnosy: + sbt, davin
2015-03-04 10:38:23alexei.romanovsetnosy: + alexei.romanov
2015-03-04 10:15:48Roberto Martínezcreate