cron daemon, allaryin, 2005-03-15 23:33:09

cron daemon

nuff said, allaryin, 2005-03-15 23:46:57

need good way to hook into universal timed event daemon to fire off regular events so as to move objects away from heartbeats and call-outs.

daemon internals, allaryin, 2005-04-29 20:48:55

I am thinking very strongly about an actual unix style crontab file - and with one minute granularity on these events. Lines of thingy:

<frequency> <user/object> <closure>

Hmm... something like that. Perhaps we just store it as an array in the daemon (that way we don't lose array refs) and save it to disk every time it is updated or every time it executes.

Big question is how do we set frequency on events that are registered with the daemon? What about events that don't continue to execute ad infinitum - ie, functionality of the traditional unix at daemon?

Silly example of usage might be something like:

CRON_DAEMON->register_event(freq,this_object(),(: $1->destruct() :));

And the object would then destroy itself whenever the timer occurred.

alternative, gpfault, 2005-05-14 14:14:40

How about having individual timer objects attached to their owners?

Silly example of object nest:

old antique clock
timer (child of clock)

oldantiqueclock.c:

void on_timer(object timer)
{
AUDIO_DAEMON->play("tick.wav");
timer->rewind(1);
}

benefit?, gpfault, 2005-05-14 14:18:13

Keeping them as actual, cloned objects (think cronologically specialized "ai module") allow them to persist through worldsaves. Would simplify things IMHO.

That's my two cents. If I knew how to "objectize" the durned thing I'd have had it written already.

nt, gpfault, 2007-11-28 19:45:41

Note to self:

THIS IS NOT DGD!!!

no, allaryin, 2005-05-15 09:42:23

The point here is to reduce memory and cpu load by having a single object with one tick going to govern many things. We already have plenty of objects handling their own timing.

The daemon would save its status periodically so as to be persistent over reboots. Call_outs don't save on physical clones, so this would actually be more reliable than what you are proposing.

Regardless, physical clock objects would be very cool furniture for players - and would require incredible skills to craft. They would also probably plug into the cron daemon to handle their ticks ;)

Well that would work too..., gpfault, 2005-05-25 13:52:42

Sorry if I was out of line but I'm a little paranoid about persistency after watching my variables vanish.

Yes and maybe, acius, 2005-05-24 18:04:46

This is not a bad idea. The main problem it is capable of solving is the too-long-execution in call_out's bug. Basically, you'd give the thing its own heart_beat (NOT a call_out), and then have it process something like a call_out queue.

An easy way to do it is to override call_out, make it a simul_efun, and handle everything inside the simul_efun object. I've been pondering the virtues of doing things this way for a while.