From owner-svn-src-all@FreeBSD.ORG Wed Oct 17 11:21:31 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BB15A25; Wed, 17 Oct 2012 11:21:31 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id E6EAA8FC12; Wed, 17 Oct 2012 11:21:29 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q9HBLH2f030730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Oct 2012 22:21:19 +1100 Date: Wed, 17 Oct 2012 22:21:17 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: d@delphij.net Subject: Re: svn commit: r241625 - head/usr.sbin/cron/cron In-Reply-To: <507E6901.8040801@delphij.net> Message-ID: <20121017215857.L4043@besplex.bde.org> References: <201210170044.q9H0iZHo055977@svn.freebsd.org> <507E6901.8040801@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-CMAE-Score: 0 X-CMAE-Analysis: v=2.0 cv=G5JEiKY5 c=1 sm=1 a=bSy518SJfeoA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=LxQcZHavKNQA:10 a=6I5d2MoRAAAA:8 a=SNAVdp33c4qXQ2tJE_EA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: svn-src-head@FreeBSD.org, Maxim Sobolev , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 11:21:31 -0000 On Wed, 17 Oct 2012, Xin Li wrote: > On 10/16/12 5:44 PM, Maxim Sobolev wrote: >> Author: sobomax Date: Wed Oct 17 00:44:34 2012 New Revision: >> 241625 URL: http://svn.freebsd.org/changeset/base/241625 >> >> Log: o Use nanosleep(2) to sleep exact amount of time till the next >> second, not multiple of 1 second, which results in actual time to >> drift back and forth every run within 1 second of the actual action >> has been set for. >> >> Suggested by: Ian Lepore >> >> o Schedule the first run in 1 second after starting up, not on the >> boundary of the next minute, which results in the every_second >> jobs not being run. > >> >> for (;;) { - seconds_to_wait = (int) (TargetTime - >> time((time_t*)0)); + gettimeofday(&ctime, NULL); > > Could you please replace this with clock_gettime(CLOCK_REALTIME_FAST)? > This also gives us time in timespec, suitable for use with nanosleep, > plus save some code for the subtract helper. CLOCK_REALTIME_FAST_N_BROKEN should never be used. It isn't even fast on systems with fast timecounter hardware, since the syscall overhead dominates the time. It is broken since times read by it are not ordered relative to times read by CLOCK_REALTIME. Using CLOCK_REALTIME would be good. cron should also consider using CLOCK_MONOTONIC. cron is one of the few things that needs real time instead of monotonic time for most things, but perhaps it should check the monotonic time occasionally in case someone stepped the real time crazily. For checking things every second, monotonic time is probably best, but most things in crontabs want real time. nanosleep() is quite broken here, and use of CLOCK_REALTIME_BROKEN_OR_NOT is incompatible with use of the broken nanosleep(). POSIX specifies that nanosleep() sleeps in intervals measured by CLOCK_REALTIME, but in FreeBSD it sleeps in intervals measured by CLOCK_MONOTONIC. POSIX specifies clock_nanosleep(), which can sleep in on any clock, and is probably what is wanted (with CLOCK_MONOTONIC) in most cases, but FreeBSD doesn't implement this. FreeBSD does implement some other POSIX APIS that can get timeouts on any clock. Perhaps these can be used to implement clock_nanosleep() in a library, but I'm not familiar with them. sleep() uses nanosleep() so it sleeps on the same wrong clock as nanosleep(). sleep() existed before clock ids were dreamed of, so this is more broken for it than for nanosleep(). It originally had no option except to sleep in real time, so POSIX had to specify that it keep sleeping on the clock id for that time once clock ids for sleeping became available. Bruce