Re: Gsoc 2014 project proposal

[Andrea Francesco Iuorio <andreafrancesco dot iuorio at gmail dot com>]

> If atomic operations are needed within your implementations of C11 threads
> functions (rather than just within the pthread functions that your
> implementations of C11 threads functions call) then it will be necessary
> to use glibc's internal <atomic.h> facilities rather than relying on C11
> atomic being available; glibc supports building with a range of GCC
> versions.

Uh, i didn' t knew about it, but i think i can mantain the purpose to
implement some other C11 features if i have some spare times.

> Also, learning about and working out a plan for namespace issues will be
> important.
>
> 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 )

> Namespace issues also apply to the header threads.h.  I imagine you'll
> want, for example, the C11 type mtx_t to have the same layout as the POSIX
> pthread_mutex_t, so that C11 functions can be thin wrappers around the
> POSIX ones, converting pointers to one type to pointers to the other.  But
> you can't just do "typedef pthread_mutex_t mtx_t;", because the name
> pthread_mutex_t is in the user's namespace when <threads.h> is included
> (C11 doesn't have the POSIX reservation of all *_t type names).  So the
> first step might be to split up <bits/pthreadtypes.h>, into one bit that
> defines the type layout (not defining anything outside the implementation
> namespace) and a separate bit that defines the pthread_*_t names (and
> <threads.h> would only use the first of those bits, then define its own
> names).
>
> But you can't do "typedef __pthread_mutex_t pthread_mutex_t;" either,
> because in C++ the first typedef name given to a struct or union without a
> tag determines the name for mangling purposes, so is part of the ABI that
> can't change.  Thus you probably need to define the contents of the union
> without a typedef for it, and then each header would declare a separate
> union with those contents, using different typedefs, and pointer casts
> would be used in the C11 threads implementation.
>
> Both the above issues could to a large extent be addressed through
> incremental cleanup patches - though to know what's useful, you need to
> review the relevant parts of the C11 standard enough to identify the
> pthreads functions and types you'll want to use in implementing C11
> threads.

So, i can' t use a simple typedef because the type pthread_*_t is
something in userland. This make sense as the functions name problem.
I really didn' t think about it, it is the first time i try to create
a system library. But i can' t also create a typedef __pthead_*_t
because C++ don' t allow it ( and this it something that i didn' t
honestly know ). So you suggest to create a struct or union that
encapsulate the original type in the type i want. Am i right ? I need
to know if i understand the problem correctly.

>> 19 May - 22 June
>>
>> This period will be used for the basic implementation: thread data
>> structures, thread handling and mutex basic managment.
>>
>> N.B. 23 June - Mid term evaluation. My primary goal is to have a basic
>> and working function subset before the evaluation that, if possibile,
>> could pass the patch review.
>
> Note that when adding each function, you should also write testcases for
> it for the glibc testsuite.
>

I learned the existence of glibc testsuite today while i was reading
about the commits procedure. I' ll specifiy explicitally in the next
revision.

> --
> Joseph S. Myers
> joseph@codesourcery.com

Thank you for your feedback, i' m attending your response.

-- 
Andrea Francesco Iuorio
Student in Computer Science, Università degli Studi di Milano
andreafrancesco.iuorio@gmail.com - GPG Key