[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1406308202.6438.63.camel@eris.loria.fr>
Date: Fri, 25 Jul 2014 19:10:02 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: C11 threads
Hello,
Am Freitag, den 25.07.2014, 11:41 -0400 schrieb Rich Felker:
> 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.
Ideally, yes. For the time being we can mark this feature as
"experimental", I could even maintain this separately, if you
want. But honestly I don't expect much reaction from anywhere.
> > > > 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.
Basically what I had from the start is the variant with two sets of
weak aliases.
> The latter also allows us to add alternative implementations for the
> C11 ones later on an incremental basis, if we want to.
I don't think that the weak alias approach inhibits this in any way.
> 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,
The weaker semantic is effectively too weak, and there are ongoing
efforts to amend that.
The advantages that I see that this doesn't need all that attr stuff
and has no concept of cancellation.
> and definitely allows smaller size if the application
> only uses them (but of course makes libc.a and libc.so larger).
If we use weak aliases, this basically blows up the symbol table a
bit.
When I strip my test executable, it is impressively small.
> 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.
The only types that seem to be in bits are mutex and condition. All
others seem to be arch independent.
On the long we should probably have __pthread names in the alltypes.h
files and typedef these in pthread.h and threads.h respectively.
> As for the constants, which ones are
> you talking about?
the mtx_ constants are the critical ones.
thrd_error and friends can easily be mapped to EXXX error codes from
errno.h. Since these names are all reserved anyway, including errno.h
shouldn't do much harm.
> 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.
the mtx_ ones are basically flags, just as the PTHREAD_MUTEX_ ones.
This fits well with the actual values of these in musl.
And then there is TSS_DTOR_ITERATIONS versus
PTHREAD_DESTRUCTOR_ITERATIONS, not a big deal. We just have to agree
on something.
> Also this is one area where we still
> need to be careful to match the glibc ABI.
Sure. In particular we shouldn't change any existing ABI.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
