[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1406286404.6438.38.camel@eris.loria.fr>
Date: Fri, 25 Jul 2014 13:06:44 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl <musl@...ts.openwall.com>
Subject: Re: C11 threads
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.
> 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.
> > 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?
> > - 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.
> > - pthread_create and thrd_create are still too tightly linked
> > together. It would be good to split the corresponding file in two,
> > but this would make maintenance a bit more difficult.
> >
> > - there are still some symbols missing, for some of the functions
> > that I implemented as macro. work for a winter day
> >
>
> i assume you just have to add a ptototype before the macro
> definition and provide a trivial wrapper implementation
yes, was my thought, too.
> > - I don't have much tests for all of this
>
> >
> > /* Don't create just additional symbols for the simple reason that the
> > return type of the POSIX and C11 functions are different. */
> >
> > int __pthread_once(once_flag *, void (*)(void));
> > // void call_once(once_flag *flag, void (*func)(void));
> > #define _call_once(FL, FU) (void)__pthread_once((FL), (FU))
> > #define call_once _call_once
> >
>
> the additional symbols are necessary
>
> and _[a-z] is not reserved for arbitrary usage for
> the implementation (only for file scope identifiers)
Yes, I know, just was a temporary hack to get things going.
> > /* Best of all worlds, these are just weak aliases */
> > int cnd_broadcast(cnd_t *); // pthread_cond_broadcast
>
> posix is not yet aligned with c11, but i think they will
> require inequal function pointers for these functions
The term "inequal function pointer" had nothing pop up. Could you give
a reference to the relevant part in POSIX that makes the requirement
for a "strong" symbol?
Thanks
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.
