Date: Wed, 21 Dec 2011 10:22:55 -0700 From: Warner Losh <imp@bsdimp.com> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <6CCA5C04-FC68-4B5F-911A-5F26EBFA296F@bsdimp.com> In-Reply-To: <78246.1324394062@critter.freebsd.dk> References: <78246.1324394062@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6CCA5C04-FC68-4B5F-911A-5F26EBFA296F>