From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5598 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: C11 threads Date: Fri, 25 Jul 2014 11:41:41 -0400 Message-ID: <20140725154141.GC4038@brightrain.aerifal.cx> References: <1406282437.6438.34.camel@eris.loria.fr> <20140725104056.GO9928@port70.net> <1406286404.6438.38.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1406302925 10358 80.91.229.3 (25 Jul 2014 15:42:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Jul 2014 15:42:05 +0000 (UTC) To: musl Original-X-From: musl-return-5603-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 25 17:41:56 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XAhd5-0000w9-FU for gllmg-musl@plane.gmane.org; Fri, 25 Jul 2014 17:41:55 +0200 Original-Received: (qmail 26020 invoked by uid 550); 25 Jul 2014 15:41:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26012 invoked from network); 25 Jul 2014 15:41:54 -0000 Content-Disposition: inline In-Reply-To: <1406286404.6438.38.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5598 Archived-At: On Fri, Jul 25, 2014 at 01:06:44PM +0200, Jens Gustedt wrote: > Hi, > thanks a lot for your feedback. > > Am Freitag, den 25.07.2014, 12:40 +0200 schrieb Szabolcs Nagy: > > * Jens Gustedt [2014-07-25 12:00:37 +0200]: > > > after I have seen that gcc since 4.9 has a working implementation of > > > atomics, I convinced myself to implement C11 threads within musl. > > > > > > > the conclusion about threads.h was that it should be > > abi compatible with glibc so we are waiting for them > > They have that has a student summer project, so it seems to have low > priority for them. Their GSOC funding for the project fell through due to missed deadlines, so it's now an unfunded student project if it's even moving forward at all. That may be the reason. :( > > so i think you should coordinate with libc-alpha too > > > > > Choices : > > > > > > - all types are just the corresponding POSIX types > > > > > > > if glibc does the same then it's ok > > At least from the project description it seems that they prospect an > incremental implementation. Yes, that was their decision and they were generally uninterested in discussing whether it was the best decision. I tend to agree that it's the right choice, but thought it could use more discussion before a decision was made. > > > Issues : > > > > > > - a lot of C11 are just weak symbols. to avoid polluting the link > > > space of a C11 application, I had to transform a lot of POSIX > > > function symbols into weak symbols, too. > > > > > > i think this not ok: posix usually requires inequal > > function pointers for all public functions > > C11 requires that the namespace not be polluted. > > That conflict could be solved conveniently and easily by > > (1) compiling the same files twice and replacing the pthread symbol > by the other in the second compilation > > (2) copy the .o file and to some ld magic > > Which one to choose? Neither of these is very reasonable. Probably the best is to namespace-protect (i.e. prefix with __ and add the external name as a weak alias) all of the pthread functions which need to be used for implementing C11 functions, then add either second weak aliases (if the equal function pointer issue is not a problem and the signature is identical) or thin wrappers (probably my preference anyway) for the C11 functions to call the __pthread ones. The latter also allows us to add alternative implementations for the C11 ones later on an incremental basis, if we want to. I generally don't like the whole C11 threads mess, but the one potential advantage they have is having weaker semantics which may allow better performance, and definitely allows smaller size if the application only uses them (but of course makes libc.a and libc.so larger). The other thing nice about eventually having mostly-separate (I say mostly because thread creation/destruction still needs to be unified, I would think) code for POSIX and C11 would be that we could avoid having permanent restrictions on the namespace usage for pthread functions. > > > - the include file threads.h includes pthread.h, so the namespace of > > > the C11 implementation is poluted with the pthreads stuff > > > > > > > i think this is not ok in the final version > > yes, I thought so, too. I would have to find a convenient way to just > include the magic constants. Or would it be ok, to just duplicate > them. > > For the types this should be easy to have them typedef'ed to some > opaque struct. For the types that vary per-arch, I don't see any way around having them in the alltypes.h.in bits. As for the constants, which ones are you talking about? I don't think it's so easy to directly use the POSIX ones for C11 since they have some different semantics (flag bits vs enumeration-style) for a few. Also this is one area where we still need to be careful to match the glibc ABI. Rich