From owner-freebsd-threads@FreeBSD.ORG Wed Dec 21 17:27:43 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08CA106566C; Wed, 21 Dec 2011 17:27:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id AC10D8FC13; Wed, 21 Dec 2011 17:27:43 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBLHN2ST079514 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 21 Dec 2011 10:23:05 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <78246.1324394062@critter.freebsd.dk> Date: Wed, 21 Dec 2011 10:22:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6CCA5C04-FC68-4B5F-911A-5F26EBFA296F@bsdimp.com> References: <78246.1324394062@critter.freebsd.dk> To: "Poul-Henning Kamp" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 21 Dec 2011 10:23:06 -0700 (MST) Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: [Patch] C1X threading support X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 17:27:44 -0000 On Dec 20, 2011, at 8:14 AM, Poul-Henning Kamp wrote: > In message <4EF09FFD.7768.B66F73ED@s_sourceforge.nedprod.com>, "Niall = Douglas"=20 > writes: >=20 >>> And maybe, in trying to express that using a real-world example, >>> the standards comittee would realize that UTC was a mistake, and >>> changed the timeout argument to a relative time interval instead, >>> like for instance the poll(2) system-call. >>=20 >> There was some very good argument against relative periods. I=20 >> honestly can't remember what that was. It was a long time ago. >=20 > There are no good arguments against relative periods, in particular > not when the crap they are replaced with requires you to put a > loop around the sleep to get the desired behaviour in the first > place. >=20 > The fact that you cant even remeber the argument doesn't in any way > make it any more convincing. When time changes in the system, as it is wont to do occasionally, then = absolute time arguments will screw you. There's no way to get them = right that isn't a massively horrible kludge. Let's say you want to = sleep for no more than 1s. You get the time, add 1s to it, get = preempted, ntpd or somebody else notices the clocks are 1 year fast and = adjusts, you get a quatum again and make the call with a timeout now = 1-year in the future. What could possibly outweigh that negative? Warner