Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Scheduling without cron or modules

by Samn (Monk)
on Aug 10, 2003 at 00:26 UTC ( #282518=perlquestion: print w/replies, xml ) Need Help??

Samn has asked for the wisdom of the Perl Monks concerning the following question:

Heya monks. I'd like to write a scheduling agent to run scheduled tasks for my entirely Perl driven community site. I don't want to use Cron or any modules, for a good reason.

In this scheduling agent, I want to assign multiple events to times, obviously run them on time, and then reset the time for that event's next run. Precision isn't important, only reliability.

I could store the event schedule in a file, or the database, and read it in every time the engine is started/the website receives a hit. This would fire something like 80,000 times a day (looking for four or five events) and be very wasteful.

I had the other idea to write a separate script ("monitor.cgi") that would load the list of events into memory on start, and then begin a sleep, check, sleep cycle. Meanwhile, the main engine would check every hit to just make sure monitor.cgi is still up and running. In other words, the monitor would always be running.

Which of these options is the biggest drain? It seems obvious, but I don't know what's going on with the hardware when a script is sleeping and try to avoid assumptions.

Are there any other solutions? If the monitor idea sounds like a good one, I'll have One More Question™ regarding how to check that a particular script is running.

Thanks in advance to any solutions, advice or scolding!

Replies are listed 'Best First'.
Re: Scheduling without cron or modules
by Zaxo (Archbishop) on Aug 10, 2003 at 01:08 UTC

    belg4mit has written a cron daemon in perl. See a cron; in perl. I haven't tried it, but it appears to be as you specify.

    You say,

    I don't want to use Cron or any modules, for a good reason.
    I'm always curious to know those reasons. They are not usually as good as one thinks.

    After Compline,

      As am I, I purposely left it out to keep the post more to the point.

      I'm writing a pre-packaged community website engine that'd I'd like to eventually distribute. I'm aiming for a very easy to use system, and very easy to read code. It should be as easy to set up, and require as little technical know how, as GreyMatter, MoveableType, Blogger and ilk.

      I figured to this end I should avoid -relying- on any non-core modules, or cron, which in my Host Hopping adventures hasn't seemed to be so universally available.

      This engine of mine supports a variety of plugins, like a chatroom modifier that uses Chatbot::Eliza, and advanced users will probably prefer an option to tie the software into cron. I still want a substitute coded in by default.

      I have cron, I use cron, cron is good. But I think a less efficient/accurate mimic in my software would encourage wider use. Don't hesitate to let me know if you have a better point.

        Schedule::Cron works very nicely for these types of things. Even if you don't want to use it looking at the implementation might give you a good starting point.
        If it is going to be pre-packaged anyway, use whatever modules you want (such as the excellant Schedule::Cron) and just be sure to include them in the package you distribute. That isn't hard at all (as long as they are pure Perl). Just update the versions in your package when you release updates to your core engine, and allow for advanced users to specify that the system installed versions of the required modules be used instead. Simple.
        vroom makes a good point. If you're going to be packaging up your goodies for the less technically inclined, it shouldn't be all that hard to embed a good cron module into your package. The same goes for any module that isn't part of the perl core, but would save you development time and offer a well-tested solution for issues that might otherwise be tricky for you or even risky for users of your package.

        Of course, when the CPAN module you embed or adapt into your package undergoes an important fix, you'll need to update your package accordingly. This could also be a very good feature for customers who are not "CPAN-enabled" -- they need only rely on you to make sure that their installation takes care of all that bug-fix/web-security stuff, so long as they just keep up to date on this one complete package that they get from you.

Re: Scheduling without cron or modules
by cees (Curate) on Aug 10, 2003 at 01:02 UTC

    If your reason for not using cron is that it is not available on the box, then you could consider using cron on a separate box and having it call a cgi script on your server at the given times (obviously with some authentication). Of course you need a separate box for this to work.

    Also, you could do a google search on 'cron service'. I noticed a few companies that offer cron like services (although I have never used them, and could not give you a recommendation on them)...


    - Cees

    Update: Now that I know your reason for not wanting to use cron, I realize that my answer doesn't help you one bit. So you can ignore this message. For future questions, the more info the better. There is no such thing as too much info (There is always the 'readmore' tag if you are worried about the length of your post). Sorry I couldn't be of more help, but it looks like you got some good answers below...

Re: Scheduling without cron or modules
by bean (Monk) on Aug 10, 2003 at 08:29 UTC
    I like the "cron in perl" idea offered in a previous post, but either of your solutions could be made much less wasteful with the simple addition of only having a 1 in N chance of firing. In your case, N might be somewhere around 800 - it would go off ~100 times a day, which should be often enough. The thing I don't like about the "monitor.cgi" idea is the name - it implies that you're planning on running it as a cgi (which I don't think will work, because IIRC cgi's terminate if the client disconnects/times-out). A script that runs all the time is a daemon (so it would be "") - and if it's robust enough, it shouldn't need monitoring. So, we're back to the "cron in perl"...
      Thanks bean, good point. I'm one of those Perlers who often forget Perl can actually be used for things other than web pages, so cgi is always the extension that comes to mind.

      I didn't intend to run it as CGI.

      Even BETTER than your suggestion, though, is what I found digging through Schedule::Cron. Note the time of the next scheduled event, and sleep until then (reloading/starting again if an event is added or deleted). It makes perfect sense, but I had completely missed it.

      At my skill level, this is all toward the upper edge of my abilities and I look forward to tackling it. This whole "forking" and "SIGALARM" voodoo. As per usual, it likely wouldn't happen without PerlMonks consultation.

        I'd just like to point out that webhosting providers often somehow check for processes that are running for too long (suspecting that they are daemons, which are usually not allowed), and kill them.
        this might be a problem if your pseudo-cron sleeps() for hours at a time in the background, i guess, and severly limit the 'ease of installation' factor...
        just my two centimos, YMMV

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://282518]
Approved by The Mad Hatter
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (8)
As of 2022-05-24 09:13 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (82 votes). Check out past polls.