Charles-François Natali added the comment: IMO, this shouldn't be implemented atop thread, but ought to be a regular thread pool: this way, you won't get behind if some task takes too long to execute, the thread pool can start new threads as needed, and we get the general work submit/cancel (through future) for free. Also, it would probably deserve a new interface in concurrent.futures, as ScheduledExecutor, with new schedule(delay, fn, *args, **kwargs) and schedule_periodic(delay, fn, *args, **kwargs) for one-shot and periodic calls.
It would be much more consistant than an ad-hoc implementation in the threading module. ---------- nosy: +neologix _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue995907> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
