From: Carlos O'Donell <carlos@baldric.uwo.ca>
To: Ulrich Drepper <drepper@redhat.com>
Cc: libc-alpha <libc-alpha@sources.redhat.com>,
parisc-linux@lists.parisc-linux.org
Subject: [parisc-linux] Re: [PATCH] linuxthreads for hppa (1/3)
Date: Wed, 15 Oct 2003 14:33:29 -0400 [thread overview]
Message-ID: <20031015183329.GG31385@systemhalted> (raw)
In-Reply-To: <3F8D85B9.8090504@redhat.com>
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.
c.
next prev parent reply other threads:[~2003-10-15 18:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-10 20:44 [parisc-linux] [PATCH] linuxthreads for hppa (1/3) Carlos O'Donell
2003-10-12 21:33 ` [parisc-linux] [PATCH] linuxthreads for hppa (1/3, Round 2) Carlos O'Donell
2003-10-12 21:33 ` Carlos O'Donell
2003-10-15 5:13 ` [parisc-linux] Re: [PATCH] linuxthreads for hppa (1/3) Ulrich Drepper
2003-10-15 5:40 ` Carlos O'Donell
2003-10-15 5:56 ` Ulrich Drepper
2003-10-15 14:26 ` Carlos O'Donell
2003-10-15 14:26 ` Carlos O'Donell
2003-10-15 17:36 ` Ulrich Drepper
2003-10-15 18:33 ` Carlos O'Donell
2003-10-15 18:33 ` Carlos O'Donell [this message]
2003-10-15 17:36 ` Ulrich Drepper
2003-10-15 5:56 ` Ulrich Drepper
2003-10-15 5:40 ` Carlos O'Donell
2003-10-15 5:13 ` Ulrich Drepper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031015183329.GG31385@systemhalted \
--to=carlos@baldric.uwo.ca \
--cc=drepper@redhat.com \
--cc=libc-alpha@sources.redhat.com \
--cc=parisc-linux@lists.parisc-linux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.