doPoll timeout problems

Wim Lewis <[email protected]>
Newsgroups gmane.comp.python.twisted
Message-ID <[email protected]>
Scott, Barry wrote:
> We are seeing a problem with poll being called very often and think that the 
> problem is in the timeout calculation.

I think you're right and that changing that line to use ceil() is a good 
fix. It does mean that some timeouts might happen up to a millisecond 
later than they would otherwise, but I think that's better than having the 
reactor spin-wait to consume time.

This probably only happens with the poll() reactor, because all the other 
APIs seem to have higher resolution timeouts --- select, epoll, kqueue, 
ppoll all have microsecond or even nanosecond timeout parameters.

If there is code that actually needs sub-millisecond timeout resolution it 
might be possible for Twisted to implement that using setitimer() or 
similar, but that seems like a lot of work to support an exotic use case 
that could be handled more efficiently by switching to epoll etc.

I checked the history of that line of code and it dates back all the way to 
the first poll()-based event loop implementation in 2001. Perhaps computers 
were slow enough back then that a call to poll() would take most of a 
millisecond :) but in any case the rounding-down behavior doesn't seem to have
been explicitly chosen.

> These _updateLogDateTime call seems to be a lot of complexity for no 
> benefit. After all time.time() is very fast on Linux, why cache the log 
> time strings?

Perhaps it is not the time() call but the cost of converting a time value 
to a string that is being avoided here? Sometimes the calendar/date 
calculations are expensive.

It seems to me that HTTPFactory could be implemented more efficiently by 
only caching the string on demand, and then setting a timer to clear the 
cache (reset _logDateTime to None) at the next 1-second mark. On a 
heavily-loaded server, that would have the same properties as the current 
code; but on a lightly-loaded server it would avoid running that callback 
unneccessarily. And overall I don't think it's any more complicated than 
the current implementation.

Wim.

_______________________________________________
Twisted-Python mailing list
[email protected]
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.