Re: Gsoc 2014 project proposal

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Feb 26, 2014 at 08:34:07PM +0100, Andrea Francesco Iuorio wrote:
> > The idea is to implement C11 threads on top of pthreads - but the pthreads
> > functions are in the user's namespace in C11.  That is, it's valid for a
> > C11 program to define its own pthread_* functions, and use them, and also
> > use the C11 threads functions.  This means that implementations of the C11
> > threads functions can't use pthread_* functions under those names - they
> > need instead to use __pthread_* names.  Many pthread_* functions are
> > already defined with such __pthread_* names (with pthread_* being weak
> > aliases for them), but if you need functions that aren't, they'll need to
> > be changed into weak aliases.  Furthermore, this applies to anything used
> > indirectly by the functions you use.  For example, pthread_create uses
> > mmap, but that's not a C11 function, so it will need to change to use
> > __mmap, so that a C11 function using thrd_create can also define its own
> > mmap function.
> 
> I didn' t think about it. It perfectly make sense since pthread ( and
> its internal types ) is an userspace library and so the user can
> define their own pthread functions. I' ll change my implementation
> plan to include some time to study what pthread function i' ll need
> for the project while i' m reading the C11 reference. At the moment i
> don' t know what pthread ( and functions in general ) i should need to
> create aliasies but that means that, during the first period, i should
> make a precise plan of what functions i should change in glibc ( and
> than change them )

I think your use of the word "userspace" is somewhat imprecise; if
you're using it to mean that libpthread is something outside of "the
implementation" and in the domain of what applications can
override/replace, you're wrong. Formally (wrt POSIX), the pthread
functions are just as much a part of the implementation as stdio,
locale, etc. With regards to implementation, glibc (including its
dynamic linker) assumes properties of its own implementation of
pthreads. Long long ago there was a time when you could treat it like
a "third party library" and swap out one libpthread for another; the
only reason this was possible is that none of them were removely
correct with regard to POSIX semantics.

What Joseph meant about namespaces is that pure ISO C applications
which are not written to POSIX are not forbidden from using the
pthread_* namespace for their own purposes, possibly defining external
functions which would seem to conflict with pthreads. This does not
make it valid to interpose alternate pthread implementations in a
program using anything from POSIX that's not in ISO C; rather it just
means these identifiers are not "special" with respect to ISO C, and
thus an implementation where programs written to plain ISO C end up
indirectly referencing these non-reserved identifiers as part of
calling standard functions is non-conforming.

Rich