This is the mail archive of the 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] linuxthreads for hppa (1/3)

On Wed, Oct 15, 2003 at 10:36:57AM -0700, Ulrich Drepper wrote:
> > How do you propose it be handled? All arches define __LT_SPINLOCK_INIT
> I'm talking about this __LOCK_INITIALIZER -> __LOCK_ALT_INITIALIZER
> change.  Why do you claim the right to rename the symbol?

The original __LOCK_INITIALIZER did not have a cast 
to (int).

The new __LOCK_INITIALIZER does not have a cast to 
(struct _pthread_fastlock)

When using a structure in an assignment within a function the named
initializer version is required, such that the constructor can setup the
object. Instead of using __LOCK_INITIALIZER which is already expected to
be of a certain type without a cast, I created __LOCK_ALT_INITIALIZER
and made 2 changes instead of the 6 or more that would be required had I
reversed the semantics.

The same logic applied when I defined __LT_SPINLOCK_ALT_INIT. In order
to minimize changes the default behaviour is to use the named init, the ALT
behaviour does not. The ALT case is hidden inside
__pthread_lock_define_initialized and cannot use a cast.

Should you like, I could reverse the behaviour of the above
__LOCK_ALT_INITIALIZER, but I would have to make changes to initspin.h
and pthread.h so the initialization macros work.

My net is currently down and I cannot verify if initspin.h and pthread.h
are the only files that would require changes.

In summary I chose the semantics to _minimize_ code change. If you
prefer header changes over core .c file changes then I can reverse the
semantics of __LOCK_INITIALIZER with that of the ALT version.


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