From: "Chris McDonough" <chrism@digicool.com> [snip]
As a side note, I do not like the fact that Xron requires you to use special DTML methods. I suppose this is a requirement in this architecture due to the fact they need to be autocataloged, but I don't really like that feature either :-).
The use of special DTML methods was a intended as a "proof of concept" as well as as a simple implementation route to get something running in the short term. It would be preferable to have the ability to schedule any method -- including python methods, perl methods, external methods, .... However, any more general implementation has to address the same issues addressed by the special DTML method of Xron: 1. Automatic reflection of changes to a method's scheduling parameters in the dispatcher's table of scheduled methods. Xron DTML methods are catalog aware for this reason. Autocataloging could clearly be implemented by other means. 2. Making rescheduling decisions inside the scope of the current transaction. Waking up the dispatcher (if the sleeping model is used) when the schedule table changes. For these reasons, Xron DTML Methods have "trigger" methods. A trigger method is like a __call__ method, but it deals with the mechanics of scheduling while leaving __call__ available for calling the method in cases (like when debugging the core logic of the method) when you don't want to mess with the schedule.
What does the Dispatcher thread do? Does it fire off worker threads?
Xron has a single dispatcher thread. This thread knows how long to sleep for until the next job needs to run.
Do you think this is this any more effective than having a producer thread do a lookup every minute to see what jobs are current, after which it should put the current jobs in a queue? E.g., as the "run" method of a separate producer thread:
def run(self,localtime=time.localtime,time=time.time,sleep=time.sleep): while 1: t = localtime(time()) sleeptime = (60 - t[SECOND]) sleep(sleeptime) for event in self.eventdata.values(): if event.isCurrent():
self.outputqueue.put(EventWrapper(event,self.reportqueue))
I don't see much of a functional difference between a polling and a sleeping model for the dispatcher. Both need a list of scheduled methods (events). I chose the sleeping model because it eliminates any granularity for the wakeup times. But it's not enough more complicated that I would consider it a design issue. [snip] -- Loren