Re: POE::Component::Cron

On Tue, Jun 09, 2009 at 02:29:24PM -0600, chris fedde wrote:
> I'm going to cc the support list to see if anyone else has some ideas.
> 
> On Tue, Jun 9, 2009 at 1:18 PM, Rob Fugina<[email protected]> wrote:
> >
> > Well, if I understand your rewrite correctly, there are two major
> > changes.  First, you rewrote my POE::Session creation into a
> > subroutine, which you then call 3 times.  Less code that way -- fine.
> > You then added a repeating "delay" event/state.  This doesn't seem to
> > have anything to do with either my problem or the POE::Component::Cron
> > module.  When I disable the "delay" state altogether, I get the
> > behavior I saw before, which is that only the "first" session gets
> > "tick"s.  Why is the "delay" stuff necessary?
> >
> 
> I suppose that we could call this a limitation of the implementation
> of Poco::Cron.  It is implemented as an external session that
> periodically posts events into sessions that subscribe to it.  If the
> client session itself does not have anything to keep it alive then the
> client session dies.    Since the Poco::Cron singleton sesson has the
> schedule events pending it does not die.
> 
> What I can't quite figure out is why the first client does not also die.

The first session spawns the P::C::Cron session (internally to
P::C::Cron) and so is waiting for the child session to finish - it has
a reason to live.

The other sessions have no aliases and POE doesn't have any reason to
keep them alive.

Perhaps P::C::Cron should refcount_increment() any session that it's
scheduling events for, and refcount_decrement() when that event is
deleted.

Of course, this means anything that relies on P::C::Cron will need to
be stricter on clean up.

Tony