From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 8 04:31:48 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95AA837B405 for ; Tue, 8 Jul 2003 04:31:48 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1EF543FF3 for ; Tue, 8 Jul 2003 04:31:43 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc01p.dialup.mindspring.com ([209.86.0.57] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19ZqhA-0002Tq-00; Tue, 08 Jul 2003 04:31:42 -0700 Message-ID: <3F0AAB50.39D36684@mindspring.com> Date: Tue, 08 Jul 2003 04:30:24 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rich Morin References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a431c29aa38c963e90ba686ef4c2420dcd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: hackers@freebsd.org Subject: Re: Adding second-level resolution to cron(8). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2003 11:31:48 -0000 Rich Morin wrote: > I have a project for which I need a generalized time-based scheduling > daemon. cron(8) is almost ideal, but it only has minute-level resolution. > So, I'm thinking about modifying cron to add second-level resolution. > > Before I start, I thought I'd ask a few questions: > > * Has someone already done this? There are a couple of programs that can do this, but they aren't cron, per se. > * Is it a Really Bad Idea for some reason? One really bad thing about using cron as your starting point is that each time it wakes up, it stats the crontab file to see if it has changed (historical cron implementations needed to be sent a SIGHUP instead). It's also lazy about time changes. The net effect of the first is that it wildly spins updating atime on the file; this is bad from a number of perspectives, but the worst thing about it is that there ar a limited number of duty cycles on things like flash memory "ATA" devices that you would use in an embedded system, so you end up having to do a lot of work to get a copy of the crontab into a ramdisk. The net effect of the second is that cron would, in effect, need to increase its rate of stat to once a second, which means sixty time less MTBF, even if we are talking a disk inode write, rather than a flash device. Again, the fix would have to be "move the crontab somewhere else". Really, this type of thing needs a timer set to go off on or after a spcific time, rather than using an interval timer, or the code needs to get a lot smarter about calculating when the next work needs to be done, and use a kqueue to watch the file for modifications, instead, so it can use a select to implement both the watching and the interval timer. It also needs to be smarter about not rereading the file every time it needs to run, and using a cached copy instead. Unfortunately, cron is not a happy program. 8-(. -- Terry