Junyeong Jeong <rhd...@gmail.com> 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 of when they come "out". Mandating such a > guarantee effectively means orchestrating a queue with a real maxsize equal > to the configured maxsize plus the total number of coroutines competing to > put items into it. Your explanation is correct technically. But without enough explanation, this behavior can confuse many users. For instance it happens to put data into asyncio.Queue at asyncio protocol callbacks by creating new task. This logic will work nicely for a long time but in the corner case the queue gets full and at the point of view of a consumer the data come out from the queue are out of order. IMHO, it would be better to add some note into the document, describing what FIFO means in regard to asyncio.Queue. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38874> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
