On Thu, 30 Oct 2008 23:45:00 +0100, Peter Jacobi <pjacobi.de@googlemail.com> wrote:

I'd like to schedule a delayed call for being done after n seconds of idling, i.e. n seconds after the last event was dispatched.

I assume this can be done by resetting the delayed call from every event handler, but this seems to be a silly solution.

Any suggestions for a better solution?

This doesn't work very well. There are events that are purely internal to reactor implementations. There's no guarantee that these won't happen at least every N seconds, preventing your code from every running. There are events that are internal to protocol implementations or other higher level APIs - for example, many protocols implement idle timeouts, so they are sources of additional timing events which you can't directly observe; as an optimization, the Twisted Web server uses a timing event that fires once a second to manage the timestamp string is needs to write to the request log. You really need to specify the set of event sources inclusively, not globally. Fortunately this doesn't mean you need to add code to every event handler you have. You can wrap each event handler in a general purpose object which resets your timer and then forwards the event to the original handler. Just wrap the handlers which should reset your countdown and all the other stuff that's going on won't get in your way. Jean-Paul

On Thu, 30 Oct 2008 23:45:00 +0100, Peter Jacobi <pjacobi.de@googlemail.com> wrote:

I'd like to schedule a delayed call for being done after n seconds of idling, i.e. n seconds after the last event was dispatched.

I assume this can be done by resetting the delayed call from every event handler, but this seems to be a silly solution.

Any suggestions for a better solution?

This doesn't work very well. There are events that are purely internal to reactor implementations. There's no guarantee that these won't happen at least every N seconds, preventing your code from every running. There are events that are internal to protocol implementations or other higher level APIs - for example, many protocols implement idle timeouts, so they are sources of additional timing events which you can't directly observe; as an optimization, the Twisted Web server uses a timing event that fires once a second to manage the timestamp string is needs to write to the request log. You really need to specify the set of event sources inclusively, not globally. Fortunately this doesn't mean you need to add code to every event handler you have. You can wrap each event handler in a general purpose object which resets your timer and then forwards the event to the original handler. Just wrap the handlers which should reset your countdown and all the other stuff that's going on won't get in your way. Jean-Paul