Rounding issues with poll_timeout in IOLoop #978

Open
schlamar opened this Issue Jan 23, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@schlamar
Contributor

schlamar commented Jan 23, 2014

If the calculated timeout from a scheduled timer is smaller than the resolution of the poll implementation, zero is passed to the underlying poll/select system call. This means that the IOLoop spins ineffectively multiple times until the scheduled timeout is finally resolved.

See this bug report against tulip for details: http://bugs.python.org/issue20311

@bdarnell

This comment has been minimized.

Show comment Hide comment
@bdarnell

bdarnell Jan 24, 2014

Owner

The error(s) are in the select module, which uses truncation instead of ceil() to convert the passed-in float to an int at the appropriate resolution. Tornado has no direct way to know what the underlying resolution is, and even if we did we have to convert back to a float to pass in to the select module. This results in the same problem again due to loss of precision. I'm not sure it's worthwhile to hack around this at the Tornado level vs just fixing the underlying modules.

Owner

bdarnell commented Jan 24, 2014

The error(s) are in the select module, which uses truncation instead of ceil() to convert the passed-in float to an int at the appropriate resolution. Tornado has no direct way to know what the underlying resolution is, and even if we did we have to convert back to a float to pass in to the select module. This results in the same problem again due to loss of precision. I'm not sure it's worthwhile to hack around this at the Tornado level vs just fixing the underlying modules.

@schlamar

This comment has been minimized.

Show comment Hide comment
@schlamar

schlamar Jan 24, 2014

Contributor

It won't be fixed in 2.7 and a there is already a proper solution in tulip: https://code.google.com/p/tulip/source/detail?r=5b7e17a75ba4b9bdaab5969a787e904137a53aee.

Contributor

schlamar commented Jan 24, 2014

It won't be fixed in 2.7 and a there is already a proper solution in tulip: https://code.google.com/p/tulip/source/detail?r=5b7e17a75ba4b9bdaab5969a787e904137a53aee.

@bdarnell

This comment has been minimized.

Show comment Hide comment
@bdarnell

bdarnell Jan 24, 2014

Owner

The tulip solution for poll() works, but the epoll one doesn't because it discards precision by converting back to a float:

>>> int(math.ceil(0.0005 * 1e3) / 1e3)
0

All of Tornado's IOLoops would have to follow the latter pattern.

Python 2.7 will receive bugfixes until 2015 (http://www.python.org/dev/peps/pep-0373/#maintenance-releases).

Owner

bdarnell commented Jan 24, 2014

The tulip solution for poll() works, but the epoll one doesn't because it discards precision by converting back to a float:

>>> int(math.ceil(0.0005 * 1e3) / 1e3)
0

All of Tornado's IOLoops would have to follow the latter pattern.

Python 2.7 will receive bugfixes until 2015 (http://www.python.org/dev/peps/pep-0373/#maintenance-releases).

@bdarnell bdarnell added the ioloop label Jul 16, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment