From owner-svn-src-head@FreeBSD.ORG Tue Oct 16 07:06:49 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 9678B773; Tue, 16 Oct 2012 07:06:49 +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 64ABE8FC0C; Tue, 16 Oct 2012 07:06:48 +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 1TO1El-0004sH-6U; Tue, 16 Oct 2012 00:06:47 -0700 Message-ID: <507D077C.6080108@FreeBSD.org> Date: Tue, 16 Oct 2012 00:06:36 -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: Adrian Chadd 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> <1350335891.1123.160.camel@revolution.hippie.lan> <20121016133233.I1358@besplex.bde.org> <507CD99D.1070606@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: Ian Lepore , src-committers@freebsd.org, Pawel Jakub Dawidek , Garrett Cooper , svn-src-all@freebsd.org, Pedro Giffuni , Bruce Evans , svn-src-head@freebsd.org 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:06:49 -0000 On 10/15/2012 9:40 PM, Adrian Chadd wrote: > Gah, I think there's quite a lot of push back on this. > > Maxim, would you please consider reverting this patch? Can we have a > discussion on the best way to do this, taking various things like > embedded and power-saving systems into effect? I am working on improved version, so that in the absence of @every_second it would revert to the previous behavior. Even though I seriously doubt that few thousand additional CPU cycles every second would make any measurable differences in any practical application. -Maxim