Date: Tue, 20 Dec 2011 10:09:23 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "Niall Douglas" <s_sourceforge@nedprod.com> Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <3065.1324375763@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 20 Dec 2011 09:48:12 GMT." <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com>, "Niall Douglas" writes: >On 19 Dec 2011 at 17:31, Daniel Eischen wrote: > >> > Obviously, had we known that from the beginning, things would have >> > been done differently. However, there was - in hindsight - a lack of >> > realisation just how expensive any significant changes would appear >> > to vendors. >> >> And why on earth would the thought of having a threading API >> significantly different from the POSIX API even be on the >> table? It boggles the mind. > >1. Because [...] Nice and fine. But can you explain, why the job is done so half-assedly ? Why are fundamentally and necessary programming tools, such as a "assert this mutex is held" missing ? Why are timescale-issues not dealt with ? For instance mtx_timedlock() operates only on the UTC scale. Where is the option to wait on an "elapsed time" timescale to not be hosed by ntpd(8) or root's setting the clock backwards during system startup ? Where did the ability to control a threads stacksize or other attributes go in thrd_create() ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3065.1324375763>