Josh Rosenberg added the comment:
Yes, five outstanding blocked puts can be bypassed by a put that comes in
immediately after a get creates space. But this isn't really a problem; there
are no guarantees on what order puts are executed in, only a guarantee that
once a put succeeds, it's
Junyeong Jeong added the comment:
Thanks for having an interest in this issue.
I thought asyncio.Queue guarantees the order of items as .put called after I
read the code. But it does not.
I attach poc code here.
In my machine, this program prints this message and exits.
$ python
Andrew Svetlov added the comment:
I still don't understand the problem.
If the queue is full new items still are added in the order of `await q.put()`
calls.
If there are multiple producers the order of adding items into the queue is
still the order of `q.put()`.
Do you have a code example
Junyeong Jeong added the comment:
> The items that haven't finished the put aren't actually "in" the queue yet,
> so I don't see how non-FIFO order of insertion violates any FIFO guarantees
> for the contents of the queue; until the items are actually "in", they're not
> sequenced for the
Josh Rosenberg added the comment:
The items that haven't finished the put aren't actually "in" the queue yet, so
I don't see how non-FIFO order of insertion violates any FIFO guarantees for
the contents of the queue; until the items are actually "in", they're not
sequenced for the purposes
New submission from Junyeong Jeong :
Hi
The python document says that asyncio.Queue is FIFO queue. But it is not true
when the queue is full and multi tasks are putting items into it
simultaneously. I know the document does not explicitly mention that
asyncio.Queue is multi producer queue, but
