Message189050
> 1. Extends an abstract interface to support of a priority
I'm not sure I see the use case for priority support, do you have a
sample use case?
Furthermore, the executor is backed by a thread pool, so tasks can be
run concurrently.
Finally, the ordering is based on real-clock time - not user-provided
timefunc and delayfunc: so the probability of having identical
scheduled time (priority is only used for ties) is virtually 0.
> and absolute time.
If you want and absolute time, you can simply do:
p.schedule(abstime - time(), fn, args)
I don't see the need to complicate the API.
> 2. Subclass sched.scheduler from this interface and implement missing methods.
There again, I don't see the need.
The goal of ScheduledExecutor is to be consistent with the Executor
interface and futures, not being backward-compatible with the sched
module.
Also, the sched module simply can't support some operations: for
example, it's impossible to have the schedule.run() method wake up
when a new event with a deadline easiest than the current one is
inserted.
Really, there is now reason to make it compatible or similar to the
sched module: this will - it it gets accepted - effectively deprecate
threading.Timer and the sched module (except that the later supports
user-provided time and delay functions, I don't know how often those
are used). |
|
Date |
User |
Action |
Args |
2013-05-12 17:08:00 | neologix | set | recipients:
+ neologix, gvanrossum, bquinlan, pitrou, r.david.murray, serhiy.storchaka |
2013-05-12 17:07:59 | neologix | link | issue17956 messages |
2013-05-12 17:07:59 | neologix | create | |
|