Archive of UserLand's first discussion group, started October 5, 1998.

scheduler.monitor review/rewrite

Author:Dave Winer
Posted:12/18/1998; 1:16:06 PM
Topic:Work on builtins.scheduler
Msg #:1437 (In response to 1434)
Prev/Next:1436 / 1438

1. Removed user.scheduler.startingup and user.scheduler.prefs.reschedule. These two confusing flags were there so that when Frontier is starting up the user can have the option of not running tasks whose time had come to run. We had the feature turned off on all our servers. If necessary, we can easily bring the feature back after we've had a chance to fully understand and streamline the performance of scheduler.monitor. The whole script was structured around this feature. I wasn't even sure the code worked.

2. The script in a sub-table of user.tasks can be an address or a script in addition to a string. This is the modern way to do it. It can also be an address to an address to an address..

3. Improved logging. This is the reason I dug into the scheduler (beyond fixing bugs). If user.scheduler.prefs.logInGuestDatabase is true, we enable a much more sophisticated logging procedure than prior to 6.0. (In 5.x and earlier the log information would go into an outline. We can't recommend people use this mechanism on a server. The new method is totally appropriate.)

You can have both methods turned on. If user.prefs.keepLog is true, we will continue to log in an outline. But you will get much less information.

4. We handle errors better. We run all scripts inside a try, and log the errors, and one script in a set won't cause any others not to run. For good luck we even run the call to scheduler.monitor from the agent within a try statement.

There are responses to this message:

This page was archived on 6/13/2001; 4:46:44 PM.

© Copyright 1998-2001 UserLand Software, Inc.