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: <2062@van-bc.UUCP>
Date: 24 Dec 88 18:13:29 GMT
Sender: root@van-bc.UUCP
Lines: 36

In <8812232110.AA01833@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
>:ARPA:	eric@topaz.rutgers.edu or eric@ulysses.att.com
>:>>memory taken up may not be worth it).
>:>I think that this might be worth it, in some form or another.
>:
>:The easy way to do this is as follows:
>:
>:	If the "cron" is run a second time, have it send a signal to the
>:	cron that is already running and then exit. This signal will tell the 
>:	running copy to read the table again.
>:
>:So, you make a change to the table and run cron again. This simply signals the 
>:cron which is already running and then exits. DropCloth worked in a similiar 
>
>	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

--
"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                                        |
+----------------------------------------------------------------------+