This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients neologix, pitrou, r.david.murray
Date 2013-05-11.17:45:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za>
In-reply-to
Content
Here's an implementation of a new ScheduledExecutor abstract class, with a concrete ScheduledThreadPoolExecutor implementation (see #995907).
The aim is to provide a flexible, efficient and consistent framework for delayed and periodic tasks, leveraging on futures. Incidentally, this supersedes threading.Timer, which is quite fragile and inefficient.

Here's a patch with test (I didn't write the documentation, I prefer to have some feedback first :-), the API is complete.

There's one thing that bothers me with the current implementation: when a future is cancelled, like for regular ThreadPoolExecutor, it doesn't get removed from the work queue right away, but only when it gets dequeued. For a delayed future, this means that one has to wait for the next scheduled execution (i.e. worst case <now> + future.period) for it to be  effectively cancelled and removed from the queue, and for the executor to be shutdown. I'm considering using a callback (Future.add_done_callback()), that's kind of hackish but I don't see any other way.
History
Date User Action Args
2013-05-11 17:45:43neologixsetrecipients: + neologix, pitrou, r.david.murray
2013-05-11 17:45:42neologixsetmessageid: <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za>
2013-05-11 17:45:42neologixlinkissue17956 messages
2013-05-11 17:45:42neologixcreate