[Zope-dev] Xron fragility

[Kapil Thangavelu]

Chris McDonough wrote:
> > 
> > > > 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?
> >
> > What if you want a small job to be done every 30 seconds?
> 
> I generally don't... I'm satisfied with cron granularity, although others
> might not be.  Do you have this requirement?
> 
> > > > It uses Client.py to run a job.
> > >
> > > Why is this?  This doesn't make any sense to me on its face.  Why not
> just
> > > call the method from a separate thread?
> >
> > Which separate thread? Do you create a new ZODB thread? That sounds as
> > if it might use quite a few resources.
> >
> > Is there a Zope API for making ZODB threads call methods on objects, as
> > signalled by other threads? I'm guessing the easiest way to do that is
> > to use Client.py to make a new http request.
> 
> Well... AFAIK, there is no such thing as a ZODB thread... there are a number
> of Python threads used by Zope.  We'd just fire off another one to perform a
> task as part of the thing that takes an event off the queue.  This might be
> naive.  I need to try it.

the real problem with a scheduler thread redesign is being able to call
a zope method directly through a zodb connection (and also the
connection limit). the zpublishing machinery is sitting atop the zodb,
and to really make the method work you need to reduplicate it AFAIK. 

This just seems inescapable to me as its fundamental to the way zope
works, i'd love to be enlightened...


Kapil