[TransWarp] PROPOSAL: refactoring of peak.running.daemons
Phillip J. Eby
pje at telecommunity.com
Wed Apr 16 10:55:10 EDT 2003
At 04:22 PM 4/16/03 +0200, Ulrich Eck wrote:
>we had two reasons because we wanted to give the Task control over
>1. avoid problems with long-running tasks, if they run longer than
> their poll/reschedule Interval.
Ah. In PEAK, the poll interval is end->start, not start->start. The task
does have control over scheduling, in the sense that it can change its
interval per-call if desired, and can raise StopRunning to signal that it
doesn't want to be scheduled any more.
>2. make it possible to chain tasks (e.g. if task X has finished schedule
> another task Y at some time)
I think that's an internal matter to the task. The scheduler doesn't care.
The main reason why I want the scheduler to do the rescheduling of a
periodic task is that PEAK has a priority-driven scheduler for periodic
tasks: if more than one task is available for execution, they are run in
>these interfaces are very specific to zope3 used as persistent
>utility/service .. so the principal is not of interest in peak.
> > I'd strongly suggest that you and Jim take a look at the Twisted "reactor"
> > interfaces (e.g. IReactorTime) and consider using them for Zope. Twisted
> > has a *very* clean and practical design, in addition to being implemented
> > for lots of platforms and special case conditions as part of an overall
> > event/scheduling loop. Even if Twisted isn't going to be integrated for
> > doing protocol servers, the interfaces are worth looking at.
>i have no information about the current state of Twisted integration,
>but i'll have a look at that stuff.
> > Some of the interfaces you described also seem unclear as to whether the
> > schedule is intended to be persistent or not. For example, you mention
> > BTrees, but then elsewhere there's a method to get all the scheduled
> > which would seem excessive if it's a persistent schedule.
>the system we designed is meant to be persistent .. so you're right it
>should probably be iterTaskTimes instead.
I'd suggest that this could be built on a lower-level core service designed
for transient in-process tasks - like the Twisted "reactor". This would
avoid reinventing wheels at that lower level, and perhaps enhance
interoperability as well.
More information about the PEAK