Gsoc 2014 project proposal
Andrea Francesco Iuorio
andreafrancesco.iuorio@gmail.com
Wed Feb 26 22:26:00 GMT 2014
2014-02-26 22:48 GMT+01:00 Joseph S. Myers <joseph@codesourcery.com>:
> For example, at least some of the bits/pthreadtypes.h headers define
> pthread_mutex_t as
>
> typedef union
> {
> struct __pthread_mutex_s
> {
> (architecture-specific contents)
> } __data;
> char __size[__SIZEOF_PTHREAD_MUTEX_T];
> long int __align;
> } pthread_mutex_t;
>
> If that's what all architectures do, one option would be:
>
> * bits/threadtypes.h defines struct __pthread_mutex_s and
> __SIZEOF_PTHREAD_MUTEX_T (and lots of other things, all in the reserved
> namespace).
>
> * bits/pthreadtypes.h, possibly now architecture-independent, includes
> bits/threadtypes.h and does:
>
> typedef union
> {
> struct __pthread_mutex_s __data;
> char __size[__SIZEOF_PTHREAD_MUTEX_T];
> long int __align;
> } pthread_mutex_t;
>
> * threads.h includes bits/threadtypes.h and does:
>
> typedef union
> {
> struct __pthread_mutex_s __data;
> char __size[__SIZEOF_PTHREAD_MUTEX_T];
> long int __align;
> } mtx_t;
>
> Or the common header could do
>
> #define __pthread_mutex_t_contents \
> union \
> { \
> ... \
> }
>
> and then the other headers would do
>
> typedef __pthread_mutex_t_contents pthread_mutex_t;
>
> and
>
> typedef __pthread_mutex_t_contents mtx_t;
>
> which would avoid duplication of the list of three union fields.
>
> There are various such options. The basic requirement is that after macro
> expansion the pthread_mutex_t definition looks like
>
> typedef union { ... } pthread_mutex_t;
>
> where the union does not have a tag, so that the C++ name mangling is
> unchanged. And, so that you can cast pointers appropriately, the two
> types need the same contents.
I think i understand now. The important thing is that i must create
the union/struct directly in the typedef and avoid renaming. If
possible i should try to mantain the pthread types structure so i can
cast between them. I don' t understand one thing in the first
solution: why do you separate the architecture-dependent data ? Just
to have the same machine-dependent code in only one place ?
Thank you for your feedback, i didn' t really know this problematic (
and i know that until i' ll try to work on it i can' t really
understand it ) but now i can reprogram my schedule thinking about it.
Have you any other advice ?
--
Andrea Francesco Iuorio
Student in Computer Science, Università degli Studi di Milano
andreafrancesco.iuorio@gmail.com - GPG Key
More information about the Libc-alpha
mailing list