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.
#!/usr/local/bin/perl
use strict;
use warnings;
use POE qw( Component::Cron );
sub foo {
my $tag = shift;
POE::Session->create(
inline_states => {
_start => sub {
my $h = $_[HEAP];
$h->{tick_limit} = 3;
$h->{tag} = $tag;
# $_[KERNEL]->yield('delay');
POE::Component::Cron->from_cron(
'* * * * *' => $_[SESSION] => 'tick'
);
},
tick => sub {
print STDERR join " ",
"Session", $_[SESSION]->ID,
"tag", $_[HEAP]->{tag},
"ticking\n";
exit if (-- $_[HEAP]->{tick_limit} == 0);
},
_stop => sub {
print STDERR join " ",
"Session", $_[SESSION]->ID,
"tag", $_[HEAP]->{tag},
"_stop\n";
},
},
);
}
foo('first');
foo('second');
foo('third');
POE::Kernel->run();
