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] Unify pthread_spin_[try]lock implementations.


> 	2012-07-09  Maxim Kuvyrkov  <maxim@codesourcery.com>

The indentation here is funny so I don't know if that's just how you were
quoting the fragment in the message or if you meant to indent the header
line in ChangeLog (which you should not).  Remember to use the date of
commit in the header line.

> 	* nptl/pthread_spin_lock.c: New file.
> 	* nptl/pthread_spin_trylock.c: New file.

These go in nptl/ChangeLog and don't get the "nptl/" prefix.

> 	ports/

These go in the separate ChangeLog.{arm,hppa,m68k,mips} files.
>From the way you quoted the fragments it wasn't clear if that's
what you meant.

> +#define SPIN_LOCK_READS_BETWEEN_CMPXCHG 1000
> +#include_next <nptl/pthread_spin_lock.c>

You don't use #include_next when you're giving the exact full file name
like this.  Just use #include.


Aside from the log nits, the generic additions look fine to me.  You can
commit those as soon as one of the affected machine's maintainers agrees.
For each machine, the changes need to be approved by that machine's
maintainer.  I'm not the maintainer for any those machines, but I would be
inclined to insist that each definition of SPIN_LOCK_READS_BETWEEN_CMPXCHG
have a comment giving the machine-specific rationale for the choice of value.
I wouldn't wait for all the machine maintainers before committing the
generic parts and whichever machine(s) are approved first.  Each machine's
bits can come along later as those approvals arrive.


Thanks,
Roland


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