Ryan Brindley added the comment:
So, the code handles timeout = 0 on systems where time.time() returns an int.
Look at the following snippet and consider 2 assumptions: (1) time.time()
returns an int, and (2) self._rlock.acquire call takes less than a second
if block:
deadline = time.time() + timeout
if not self._rlock.acquire(block, timeout):
raise Empty
try:
if block:
timeout = deadline - time.time()
if timeout < 0 or not self._poll(timeout):
raise Empty
The problem for the timeout = 0 case happens on systems where time.time()
returns a floating point number and the acquire lock takes enough time to cause
a diff in time.time() result between the deadline instantiation line and the
timeout update line.
Given that, especially the `if timeout < 0 ...` line, I thought it may have
been in the original intent for the function to handle 0 timeout when block
truthy.
That side, the whole concept of having a separate block bool arg in the first
place is a tad strange for me. Isn't it a bit redundant?
Why not just follow the underlying poll/select timeout arg logic as follows:
timeout = None, block indefinitely
timeout <= 0, non-block
timeout > 0, block timeout length
We could simplify this interaction by just removing that block arg all
together. Not that I'm asking to do that here though, but maybe in the future?
If we go down the suggested error-raising path though, I would ask that the
error not be queue.Empty -- which is misleading.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28982>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
