[TransWarp] PROPOSAL: refactoring of peak.running.daemons

[Phillip J. Eby]

At 04:22 PM 4/16/03 +0200, Ulrich Eck wrote:

>we had two reasons because we wanted to give the Task control over
>scheduling:
>
>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 
priority order.


>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 
> tasks,
> > 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.