[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 25 Jul 2014 11:41:41 -0400
From: Rich Felker <dalias@...c.org>
To: musl <musl@...ts.openwall.com>
Subject: Re: C11 threads
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 <jens.gustedt@...ia.fr> [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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
