Date: Thu, 22 Dec 2011 10:51:07 -0700 From: Warner Losh <imp@bsdimp.com> To: "Niall Douglas" <s_sourceforge@nedprod.com> Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <60BA4BA7-70B9-4B4E-9139-8F6DAC303867@bsdimp.com> In-Reply-To: <4EF36182.29429.C1336CBC@s_sourceforge.nedprod.com> References: <78246.1324394062@critter.freebsd.dk>, <6CCA5C04-FC68-4B5F-911A-5F26EBFA296F@bsdimp.com> <4EF36182.29429.C1336CBC@s_sourceforge.nedprod.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?60BA4BA7-70B9-4B4E-9139-8F6DAC303867>