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 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?


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