Path: utzoo!attcan!uunet!super!udel!gatech!bloom-beacon!think!ames!pasteur!agate!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: DCRON
Message-ID: <8812232112.AA01941@postgres.Berkeley.EDU>
Date: 23 Dec 88 21:12:35 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 15

:In article <8812230336.AA06015@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) 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.  I don't mind AmiCron polling the disk every minute at

	Sorry, I should have explained DCron's intelligence a bit more. 
DCron *DOES* check the file's timestamp every minute, just doesn't scan
the file every minute (unless the timestamp has changed).  Doing a Lock/
Examine takes virtually no CPU as the block in question is already cached
from previous Lock/Examine's.

				-Matt