Path: utzoo!utgpu!watmath!clyde!att!alberta!ubc-cs!van-bc!root
From: lphillips@lpami.wimsey.bc.ca (Larry Phillips)
Newsgroups: comp.sys.amiga
Subject: Re: DCRON
Message-ID: <2061@van-bc.UUCP>
Date: 24 Dec 88 18:13:11 GMT
Sender: root@van-bc.UUCP
Lines: 37

In <1176@dukeac.UUCP>, rsb@dukeac.UUCP (R. Scott Bartlett) writes:
>>  The major feature is that it does not scan the file every minute,
>> but calculates how long it must wait till the next scan.
> 	This doesn't allow one to modify the crontab file and expect cron to
> pick up on the changes immediately (well, a minute later).  With DCRON, if you
> modify the crontab, DCRON won't realize the change untill it has to do something
> from the old crontab.

	One way to do it would be to have a cron create a public message port. When
you ran it, it would look for this port, and if present, send a message to it
and exit. The message could mean 'update crontab', 'quit', or anything else,
perhaps based upon a command line argument.

>      I don't mind AmiCron polling the disk every minute at
> all; in fact, i use this feature to my advantage to know when the HD buffers
> have been flushed so that i can reboot (but that's beside the point).

  The same purpose is served by waiting 3 seconds after the last write.
 
>> (A further refinement
>> would be to read in the file into memory and not scan it at all from disk
>> unless it was modified, but unless you do something every minute the extra
>> memory taken up may not be worth it).
> I think that this might be worth it, in some form or another.

  Definitely.

-larry

--
"Intelligent CPU?  I thought you said Intel CPU!" 
        -Anonymous IBM designer-
+----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                |
| \X/    lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips  |
|        COMPUSERVE: 76703,4322                                        |
+----------------------------------------------------------------------+