Path: utzoo!attcan!uunet!husc6!ukma!rutgers!ucsd!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: DCRON
Message-ID: <8812262323.AA20514@cory.Berkeley.EDU>
Date: 26 Dec 88 23:23:03 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 27

:>	No need.  DCron checks the file timestamp every minute (this takes
:>essentially 0 CPU), and if it changes it aborts its (possibly long) timeout
:>for the normal scan and forces one immediately.
:
:  So you're back to going to disk anyway by looking at the timestamp.
:
:  There are  two reasons I'm not fond of the crons I've seen so far. One is the
:reuirement for a window, and the other is that it goes to disk. If you are
:going to disk anyway, you may as well read the crontab again.
:
:  Looking forward to seeing it. Looks like it is on the right track.
:
:-larry

	No No, even with only 5 buffers, the two that are needed for the
Lock/Examine are most likely cached after the first try.  And, of 
course, when it *does* access the disk it's only to read a sector or two...
it only writes (updates the log) when there is actually something to do, and
unless you have a * * * * * * entry which is run every minute, this doesn't
happen often.

	And people ask me if I'm a patient person ...  Actually, the
problem is probably due to network propogation times (or people not reading
their news backwards... ALWAYS read your news messages from the end to
the beginning so you don't make too many redundant replies!).

				-Matt