[Catalyst] [RFC] C::P::Scheduler - cron-like scheduling of events

[Brandon Black]

On 12/14/05, Andy Grundman <andy at hybridized.org> wrote:
> > A potential solution would be to make a seperate perl-based generic
> > cron daemon which can run independant of the Catalyst Engine from
> > scripts/ (let's call it catcron.pl), and have the Engine or something
> > else early in the startup process decide when and how to fire it up
> > and shut it down (fork/exec it on startup before children are spawned,
> > send it a kill signal on shutdown).  The ->config() or ->schedule()
> > data that's available statically at App start time could be written to
> > a crontab file that catcron.pl reads on startup.
>
> I think you'd run into cross-platform issues with this, especially on
> Windows.  If you manually started a server.pl version of the app like I
> mentioned above, and used a non-auto-running event, it might work just
> as good.
>

I always tend to forget (or is it ignore?) those unfortunate Windows
users :)  It's been quite some time since I've even had a dual-booted
desktop windows install anywhere (I do IE testing of my webapps via
Wine).

But still, it's not like the issues are unsolvable.

So we throw out having a truly seperate script and merge something
inbetween what I said and what you said, and we have Catalyst fork
itself or make a thread of itself (afaik, perl's builtin fork() can do
it correctly on both Windows and *nix) early during/before Engine
stuff like mod_perl children coming into being.

The forked/threaded copy, instead of running the usual Engine code and
listening for requests, monitors the Catalyst crontab file and does
sleep() loops waiting for it to change or an event's start time to
happen.  There's still the issue of shutting down the proc/thread at
server shutdown time, but I think that's cross-platform-doable as
well.

The primary gains of this (revised) suggestion over a standalone
catalyst server.pl is that it won't bind to a port and attempt to act
like a webserver, and it will always execute the actions when
requested without external pushes from wget, and there's no penalty
for long-running jobs (jobs can be forked/threaded via perl fork(),
since they're not in a specific request context or anything anyways),
and it starts and stops with the primary Cat server instead of
seperately.

The downsides is sorting out the fork/thread/kill stuff, although I
suspect between how well perl abstracts these concepts anyways and
perhaps the help of a CPAN module or two this would be doable.

-- Brandon