Date: Tue, 20 Dec 2011 09:48:12 -0000 From: "Niall Douglas" <s_sourceforge@nedprod.com> To: threads@freebsd.org, arch@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com> In-Reply-To: <Pine.GSO.4.64.1112191730110.25434@sea.ntplx.net> References: <20111216214913.GA1771@hoeg.nl>, <4EEF9235.31023.B2519C9A@s_sourceforge.nedprod.com>, <Pine.GSO.4.64.1112191730110.25434@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 POSIX threads is known to have weaknesses in its design e.g. signal handling. These BTW have been fixed in C1X and there are some significant departures from the POSIX API wherever pthreads was just plain broke. Some of these departures may - on some platforms - require rejigging the internal kernel/userspace boundary. Before you ask, no I don't know what these are, it isn't my area of expertise. 2. Because pthreads were designed a long time ago in a world where threading was simpler and likely core count was lower. There are more use models now, and originally it was thought that incorporating some elements of newer threading models would be wise. Bear in mind that C1X - unlike POSIX - has to incorporate EVERY kind of computing system thinkable. C1X needs to run - without major baggage - on everything from tiny, OSless systems right up to thousand CPU core highly proprietary systems. And it must do this while staying as backward compatible with legacy systems as possible. 3. Because pthreads is not the only major threading implementation out there. The NT/OS/2 model is hugely popular if fundamentally anti-scalable in design and pthreads don't map exactly one to one with them. For example, thread cancellation is completely missing from C1X as it would require significant kernel rewriting on NT, so it got chopped completely. It had been hoped we could come up with something which worked around the lack of thread cancellation, but we didn't make it in time. It'll be TR1 before we nail the corner cases. Right now, there are quite a few places where under the C1X API the program will just hang if things go wrong and there is no legal way out at all. That is unfortunate, but as always it's a question of resourcing and time. Most people's employers don't see how investing in standards work improves their bottom line, so a lot of the grunt work is goodwill and hobby time. 4. Because POSIX does evolve over time - indeed, its next release is same year as C1X (i.e. next year). People sit on both ISO committees and are on the Austin Working Group. There is significant cross-pollination. The changes in C1X are highly likely to become normalised in the next iteration of POSIX. So think of this way, the departures from POSIX in C1X were mostly intended as departures by POSIX from POSIX next iteration anyway. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF059DC.26433.B55D8036>