Allow specifying the function to use to get the current timestamp #558
Conversation
When creating an IOLoop instance, allow specifying the function to use to get the current timestamp.
|
This seems like a good idea, especially with the new monotonic clock functions coming in python 3.3 (pep 418). However, backwards compatibility is a problem - the absolute form of IOLoop.add_timeout won't work on an IOLoop that's using something other than time.time. In order to make this change we'd need to basically deprecate the common practice of add_timeout(time.time() + offset). We'd need to make sure that tornado itself uses the relative form where appropriate, and expose the time function from IOLoop so it can be used to construct absolute timestamps where needed (as in your change to PeriodicCallback). This sort of change would probably need to wait for tornado 3.0. |
|
I would hope that any user that goes to the trouble to specify a different timestamp function would know not to call add_timeout with time.time(). ;) |
|
Yes, but sometimes tornado calls add_timeout for you (e.g. in the httpclients), and when it does it currently uses time.time(). |
|
See also: #583 |
…onotonic. This means that calls to IOLoop.add_timeout that pass a number must be updated to use IOLoop.time instead of time.time. There are still some places where we use time.time in the code, but they are either places where wall time is desired, or non-critical deltas (e.g. printing elapsed time at the end of a request). Thanks to apenwarr and mgenti for pull requests and discussion relating to this change. (#558 and #583)
|
I've committed a time.monotonic change drawing on both pull requests. Like mgenti's version, I added a time_func argument to IOLoop's constructor. Instead of a monotonic argument to add_timeout, I simply said that all calls to add_timeout must be relative to the IOLoop's clock. This is going to be harder to audit for, but since use of a monotonic clock is opt-in I don't think it's too unreasonable (but I'm open to feedback on this point; it's not too late to change). Thanks to both of you for the pull requests and feedback. |
In our application where we use Tornado we routinely synchronize our system clock with an NTP server. Since this application is on an embedded device our system clock is very sloppy. If the time sync happens while the Tornado application is running, events may not run as expected. To help with that we have the IOLoop use a function that returns a timestamp that is monotonic.
This particular commit allows a user to specify the function to use to get the timestamp but by default uses time.time.