This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/6] Move mutex and condition variable definition to common header



On 28/03/2017 05:19, Torvald Riegel wrote:
> On Mon, 2017-03-27 at 11:24 -0300, Adhemerval Zanella wrote:
>>
>> On 27/03/2017 10:43, Torvald Riegel wrote:
>>> On Tue, 2017-03-21 at 10:40 -0300, Adhemerval Zanella wrote:
>>>> This patch sorts out pthread_mutex_t and pthread_cond_t in new files,
>>>> so new C11 types could be based on pthread types without corrupting
>>>> namespaces and exposing pthread symbols.
>>>>
>>>> Common pthread types like pthread_mutex_t and pthread_cond_t are now
>>>> defined in arch specific bits/pthreadtypes-common.h headers, while the
>>>> internal implementation is moved to bits/thread-shared-types.h.  File
>>>> pthreadtypes.h is cleaned up of those definitions and some related macros
>>>> and structures.
>>>
>>> If we are moving declarations in pthreadtypes.h around, can we just
>>> merge those that are common?  Most of the archs just use the same
>>> generic code or at least the same underlying data structure; most of the
>>> differences I remember where some additional alignment requirements,
>>> which probably could be handled by an additional macro that
>>> arch-specific files have to define.
>>>
>>
>> I would also like to consolidate the pthreadtypes definition in one header,
>> however I rather than make it on a following patchset instead.
> 
> If that's easier for you, then that's certainly okay.  I just saw that
> you are moving quite a bit of (mostly) redundant code around, and
> thought whether it would be easier to merge it first, so that less code
> needs to be moved.
> 
>> But I think
>> have the correct approach is required to avoid a double refactor.  I chose
>> to keep using the macros (__PTHREAD_COND_T_CONTENT and __PTHREAD_MUTEX_T_CONTENT)
>> because it is the most straightforward arrange, however maybe using a composed
>> struct with defines to access the direct member could be a better strategy.
>> Thoughts? 
> 
> AFAIR the differences between most of the pthread types, it mostly is a
> different alignment specifier here and there.  Things like sparc pre-v9
> and maybe hppa are exceptions, but the rest is pretty much the same
> everywhere.
> 
> Can we have just one definition of what's __PTHREAD_COND_T_CONTENT etc.
> now, and keep that in a file and include it everywhere (with additional
> modifier macros for things like the aligment specifiers, which would be
> defined in an arch-specific file)?  Or does that bring up the namespace
> problem you want to avoid?
> 

I think a pthread types cleanup is code refactor that should be done
independently of C11 thread support.  I will work on removing all the
redundant code from architectures.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]