Message188935
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. |
|
Date |
User |
Action |
Args |
2013-05-11 17:45:43 | neologix | set | recipients:
+ neologix, pitrou, r.david.murray |
2013-05-11 17:45:42 | neologix | set | messageid: <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za> |
2013-05-11 17:45:42 | neologix | link | issue17956 messages |
2013-05-11 17:45:42 | neologix | create | |
|