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<rob.fug...@gmail.com> 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
