Roundup Robot added the comment:
New changeset d393df09e139 by Georg Brandl in branch '3.3':
#20311: revert changes to 3.3 branch for now until experts have decided how to
resolve the issue.
http://hg.python.org/cpython/rev/d393df09e139
--
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: -serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20311
___
___
STINNER Victor added the comment:
Buildbots are happy, I close the issue.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20311
___
Charles-François Natali added the comment:
Well, now that timeouts are properly rounded, the granularity is useless.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20311
___
STINNER Victor added the comment:
Well, now that timeouts are properly rounded, the granularity is useless.
I don't think so. Please read again the issue #20452, for example this message:
http://bugs.python.org/issue20452#msg209772
--
___
Python
Charles-François Natali added the comment:
I don't think so. Please read again the issue #20452, for example this
message:
http://bugs.python.org/issue20452#msg209772
Ok, it looks better: waiting 99.9 ms took 99.6 ms and 99.9 ms, and waiting
9.9 ms took 9.7 ms. So as I said, the granularity
STINNER Victor added the comment:
Once again: a slight early wakeup isn't an issue
That's your opinion, but I disagree.
Please open a new issue with a patch, or reopen at least this issue because it
is now closed.
I already spent to much time on this issue. Buildbots are now happy, I don't
Charles-François Natali added the comment:
Once again: a slight early wakeup isn't an issue
That's your opinion, but I disagree.
Please open a new issue with a patch, or reopen at least this issue because
it is now closed.
I already spent to much time on this issue. Buildbots are now
STINNER Victor added the comment:
So, to sum up:
- you write a fragile and unelegant patch without a good reason
- you commit it without review
- you're asked several times to provide an example of the problems your patch
is supposed to solve, but don't give any
- you don't take into
Guido van Rossum added the comment:
neologix, you are getting dangerously close to attacking the person instead of
the issue. Can you live with the current state of the code? If so, let us know
(or be silent if you prefer). If you cannot live with it, please show example
code that fails or is
Roundup Robot added the comment:
New changeset f9a09b40bc17 by Victor Stinner in branch 'default':
Issue #20311, #20452: poll and epoll now round the timeout away from zero,
http://hg.python.org/cpython/rev/f9a09b40bc17
--
___
Python tracker
Guido van Rossum added the comment:
AFAICT the changes to selectmodule.c have been rolled back, both in the 3.3 and
the 3.4 (default) branches. That takes care of backwards compatibility. :-)
So what we're talking about is whether (a) the selectors module (new in 3.3)
should export a
Georg Brandl added the comment:
Since the test is still failing on at least 3 stable buildbots, I've reverted
the 3.3 changes for 3.3.4rc1.
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20311
Roundup Robot added the comment:
New changeset 900a1ff323bb by Victor Stinner in branch '3.3':
Issue #20311: Revert 033137c12d88, select.epoll.poll() rounds again the timeout
http://hg.python.org/cpython/rev/900a1ff323bb
New changeset caab3e191485 by Victor Stinner in branch 'default':
(Merge
Roundup Robot added the comment:
New changeset 90354a4c9dde by Victor Stinner in branch 'default':
Issue #20311: Revert e042ea77a152 and 7ce7295393c2, PollSelector.select() and
http://hg.python.org/cpython/rev/90354a4c9dde
--
___
Python tracker
Roundup Robot added the comment:
New changeset 3b8a2281d323 by Victor Stinner in branch 'default':
Issue #20311: selectors: Add a resolution attribute to BaseSelector.
http://hg.python.org/cpython/rev/3b8a2281d323
New changeset 4bc550c66228 by Victor Stinner in branch 'default':
Issue #20311:
STINNER Victor added the comment:
I revert all changes in select an selectors, the timeout is rounded again
towards zero, as it was before.
I applied my asyncio_granularity.patch:
- selectors.BaseSelector has a new abstract resolution property
- asyncio.BaseEventLoop has a new granularity
Charles-François Natali added the comment:
If the patch is accepted, my changes on Python 3.3 should also be
reverted.
I'm sorry, but I'm not convinced.
The selector's granularity is an implementation detail, and I don't think
it should be exposed.
Furthermore, it's not a mere function of the
STINNER Victor added the comment:
Hi,
2014-01-25 Charles-François Natali rep...@bugs.python.org:
I'm sorry, but I'm not convinced.
The selector's granularity is an implementation detail, and I don't think
it should be exposed.
I disagre, it's not a detail because it causes bugs, knowing the
Charles-François Natali added the comment:
Once again, what's wrong with your initial approach of ceiling the
timeout?
It looks like changing the rounding method doesn't solve anything.
selector.select(timeout) may still take less than timeout, so it
doesn't give any guarantee.
But what
Eric Snow added the comment:
Looks like 3b8a2281d323aa9abf497192b01cf906b98ed3d8 broke the buildbots.
e.g.
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/1533
--
nosy: +eric.snow
___
Python tracker
Eric Snow added the comment:
FYI: on my local box I saw only the 2 failed tests in test_telnetlib.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20311
___
Eric Snow added the comment:
A better example:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/1538
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20311
___
STINNER Victor added the comment:
2014-01-25 Charles-François Natali rep...@bugs.python.org:
It looks like changing the rounding method doesn't solve anything.
selector.select(timeout) may still take less than timeout, so it
doesn't give any guarantee.
But what problem does it cause if,
Roundup Robot added the comment:
New changeset f453443c96e4 by Victor Stinner in branch 'default':
Issue #20311: Fix test_telnetlib, set the resolution of the MockSelector
http://hg.python.org/cpython/rev/f453443c96e4
--
___
Python tracker
Guido van Rossum added the comment:
I don't have the energy to read all the debate here, but over on python-tulip
we continue to discuss this. Victor and I have currently agreed to drop the
math.ceil() calls from the event loop and instead simply consider any event
scheduled within
STINNER Victor added the comment:
Looks like 3b8a2281d323aa9abf497192b01cf9
06b98ed3d8 broke the buildbots.
Oh, I didn't watch buildbots, sorry. It should be fixed by f453443c96e4.
My first attempt used an attribute using a default value of None, but
it was harder to use: I had to check if
Charles-François Natali added the comment:
But what problem does it cause if, once in a while, the call takes less
than the passed timeout?
If that's the case, you'll simply perform another loop, an wake up 1ms
later, that's all.
perform another loop is my problem. If possible, I would
STINNER Victor added the comment:
Guido van Rossum added the comment:
I've lost some context, but perhaps we should have the notion of
granularity of the poll/select timeout (e.g. 1 msec), and consider
events that are in the future by less than that granularity as ready?
Then we can round
Roundup Robot added the comment:
New changeset 3637ccf9516a by Victor Stinner in branch 'default':
Issue #20311: add debug help in test_selectors
http://hg.python.org/cpython/rev/3637ccf9516a
--
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/9552
==
FAIL: test_timeout_rounding (test.test_epoll.TestEPoll)
Charles-François Natali added the comment:
==
FAIL: test_timeout_rounding (test.test_epoll.TestEPoll)
--
Traceback (most recent call last):
File
STINNER Victor added the comment:
Those failures are expected, nothing guarantees that the syscall
will take at least the amount of time specified.
Ah? The manual page of epoll_wait() says:
The timeout argument specifies the minimum number of milliseconds that
epoll_wait() will block.
Antoine Pitrou added the comment:
The timeout argument specifies the minimum number of milliseconds
that epoll_wait() will block. (This interval will be rounded up to
the system clock granularity, and kernel scheduling delays mean that
the blocking interval may overrun by a small
Serhiy Storchaka added the comment:
Isn't any blocked syscall with a timeout can be interrupted by a signal?
epoll_wait() can return EINTR.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20311
Charles-François Natali added the comment:
Ah? The manual page of epoll_wait() says:
The timeout argument specifies the minimum number of milliseconds that
epoll_wait() will block. (This interval will be rounded up to the system
clock granularity, and kernel scheduling delays mean that the
STINNER Victor added the comment:
Le 23 janv. 2014 23:21, e me.
If epoll_wait(timeout_ms) may wait less than timeout_ms seconds, asyncio
algorithm is wrong, or at least inefficient. It should loop until the time
delta is at least total_timeout seconds. See the original issue:
Antoine Pitrou added the comment:
For example, it may call again epoll_wait() if it took less than timeout
seconds and returned no event, *and* the ready list is empty.
Easy solution: add 1 ms. to the timeout before calling epoll_wait().
Perhaps we need the same kind of thing for select() and
STINNER Victor added the comment:
Le 24 janv. 2014 00:08, Antoine Pitrou rep...@bugs.python.org a écrit :
For example, it may call again epoll_wait() if it took less than timeout
seconds and returned no event, *and* the ready list is empty.
Easy solution: add 1 ms. to the timeout before
Antoine Pitrou added the comment:
It doesn't fix the case when EpollSelector.select() got an InterruptedError.
That should be very rare. I don't see a problem with retrying on EINTR.
Adding 1 ms works around the (now fixed) timeout rounding issue but I
prefered to round differently to not
Charles-François Natali added the comment:
Did you read my Tulip? Maybe I didn't explain correctly.
No, it was quite clear, and I think I understand the original issue:
calling epoll_wait(0) when passed a timeout of 0.9ms was bad, because it
led to busy-loop during 0.9ms.
But here, that's
Guido van Rossum added the comment:
I've lost some context, but perhaps we should have the notion of
granularity of the poll/select timeout (e.g. 1 msec), and consider
events that are in the future by less than that granularity as ready?
Then we can round the timeout down: if someone passes a
Roundup Robot added the comment:
New changeset 7ce7295393c2 by Victor Stinner in branch 'default':
Issue #20311: EpollSelector now also rounds the timeout towards zero, as
http://hg.python.org/cpython/rev/7ce7295393c2
--
___
Python tracker
STINNER Victor added the comment:
select.select(), selectors.PollSelector.select(), select.epoll.poll(),
select.kqueue.control() have the bug.
OS multiplexers:
- select: microsecond resolution (10^-6), timeout converted by
_PyTime_ObjectToTimeval() which converts 1e-7 to zero = BUG!
- poll:
Antoine Pitrou added the comment:
A new parameter should be added to _PyTime_ObjectToTimeval() and
_PyTime_ObjectToTimespec() to choose the rounding method.
That doesn't sound necessary. Just fix the select and selectors module so that
the final (OS-level) timeout is always 0 when the user
Roundup Robot added the comment:
New changeset 033137c12d88 by Victor Stinner in branch '3.3':
Issue #20311: select.epoll.poll() now rounds the timeout away from zero,
http://hg.python.org/cpython/rev/033137c12d88
New changeset 02f9db3e684e by Victor Stinner in branch 'default':
(Merge 3.3)
Roundup Robot added the comment:
New changeset e042ea77a152 by Victor Stinner in branch 'default':
Issue #20311: selector.PollSelector.select() now rounds the timeout away from
http://hg.python.org/cpython/rev/e042ea77a152
--
___
Python tracker
STINNER Victor added the comment:
Rounding issues with poll() and epoll() have been fixed in Python 3.3 and 3.4.
I'm now waiting for buildbots before closing the issue.
I created a new issue #20320 to address the rounding issue with select() and
kqueue (and signal.sigtimedwait).
--
STINNER Victor added the comment:
The epoll test failed on a buildbot. The test uses a short delay (10
milliseconds) and compare two different clocks: time.perf_counter() and
select.epoll.poll(). I didn't expect a failure very the greatest delay, the
test uses even shorter delay (the shortest
STINNER Victor added the comment:
Another failure:
http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.3/builds/1360/steps/test/logs/stdio
==
FAIL: test_timeout_rounding (test.test_epoll.TestEPoll)
Roundup Robot added the comment:
New changeset e1619465c49d by Victor Stinner in branch '3.3':
Issue #20311: Try to fix the unit test, use time.monotonic() instead of
http://hg.python.org/cpython/rev/e1619465c49d
New changeset 26c54e9a933b by Victor Stinner in branch 'default':
(Merge 3.3)
51 matches
Mail list logo
