From owner-freebsd-threads@FreeBSD.ORG Thu Dec 22 17:52:20 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 8E2CA106566B; Thu, 22 Dec 2011 17:52:20 +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 48E2C8FC25; Thu, 22 Dec 2011 17:52:20 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id pBMHp7pv090403 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 22 Dec 2011 10:51:10 -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: <4EF36182.29429.C1336CBC@s_sourceforge.nedprod.com> Date: Thu, 22 Dec 2011 10:51:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <60BA4BA7-70B9-4B4E-9139-8F6DAC303867@bsdimp.com> References: <78246.1324394062@critter.freebsd.dk>, <6CCA5C04-FC68-4B5F-911A-5F26EBFA296F@bsdimp.com> <4EF36182.29429.C1336CBC@s_sourceforge.nedprod.com> To: "Niall Douglas" 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]); Thu, 22 Dec 2011 10:51:10 -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: Thu, 22 Dec 2011 17:52:20 -0000 On Dec 22, 2011, at 9:57 AM, Niall Douglas wrote: > Instead of people repeatedly whinging about the system clock moving -=20= > and yes, people on standards committees are aware that system clocks=20= > can move, as they are that different cores can have different system=20= > clocks - I would be asking how does your scheduler cope with the=20 > clock moving, and how should clock syncs interact with userland? Be=20 > engineers instead of children. Ask how to solve the problem instead=20 > of complaining about split milk. Be glad you're implementing this on=20= > a POSIX system and not a non-POSIX system. Be glad there aren't a=20 > million lines of new code being needed to achieve compliance. Elapsed time since boot is typically used in cases where you need a = stable, monotonically increasing time base. Changing the system time = then becomes just a change to the boot time, but not the time elapsed = since boot. A pure monotonic time base is safe to specify absolute time = in. One that isn't monotonic, such as UTC or POSIX time_t, is unsafe. = Using it is akin to specifying a mutex system that has known races that = cannot be fixed in it. I'm sorry if my harsh remarks hurt your feelings, but the new APIs do = not learn from the well known mistakes of the past decade, so they = disappoint me. Warner