Re: Gsoc 2014 project proposal

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

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