From owner-svn-src-head@FreeBSD.ORG Tue Oct 16 07:01:06 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BF355C8; Tue, 16 Oct 2012 07:01:06 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (hub.sippysoft.com [174.36.24.17]) by mx1.freebsd.org (Postfix) with ESMTP id 223818FC14; Tue, 16 Oct 2012 07:01:05 +0000 (UTC) Received: from s173-180-43-49.bc.hsia.telus.net ([173.180.43.49] helo=[192.168.22.32]) by mail.sippysoft.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TO19E-0004rj-IL; Tue, 16 Oct 2012 00:01:04 -0700 Message-ID: <507D062A.8060109@FreeBSD.org> Date: Tue, 16 Oct 2012 00:00:58 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: svn commit: r241576 - in head/usr.sbin/cron: cron crontab lib References: <201210150821.q9F8Lobc047576@svn.freebsd.org> <20121015202615.GJ1383@garage.freebsd.pl> <1350333885.1123.153.camel@revolution.hippie.lan> In-Reply-To: <1350333885.1123.153.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 07:01:06 -0000 On 10/15/2012 1:44 PM, Ian Lepore wrote: > It appears to, which I don't think is a bad thing at all. But the way > it waits is to wake up, do some work, and go back to sleep for an > integer 1 second. That will occasionally lead to a second in which no > wakeup happens, as the "do some work" part always takes some fraction of > a second. Right, I will look into it. I believe the reason why we cannot "sleep until the next event" is that time can go back and forth in the meantime (e.g. ntpd / ntpdate), so that amount you think you can sleep can change while you are already sleeping. It should not be that hard to change it to wake up every 60 seconds if there is no per-second activity planned. Also I think some more logic necessary to ignore seconds in comparison, unless it's "every x seconds" job. Otherwise we might loose job set up for 00:00:00 by waking up say 00:00:00:01, not at 00:00:00:00 due to paging, network latency (e.g. running off nfs), etc. -Maxim