This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: TSX lock elision for glibc v11
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 14 Jun 2013 19:23:42 +0200
- Subject: Re: TSX lock elision for glibc v11
- References: <1371228488-11421-1-git-send-email-andi at firstfloor dot org>
On Fri, 2013-06-14 at 09:47 -0700, Andi Kleen wrote:
> I didn't implement any proposals that would break binary compatibility
Did you remove the breakage that you introduced? Or what are you
referring to here? (I didn't yet have the time to go through v11.)
> or prevent any
> any elision nesting, as they would make the project useless
> and the rationale was too weak.
> I didn't separate the trylock changes into new flags, as that seemed too ugly
> and overengineered, and the rationale was also weak.
> I did only do a subset identifier/comment changes requested, as for many
> there was no good rationale to do so, and my arbitary choice is as good
> as someone else's. The biggest change was __elided -> __rw_elision for
> read locks.
Review comments aren't suggestions. They are issues that need to be
discussed. Thus, if you disagree with a request in a review (which is
fine!), discuss it by directly replying to the review comment in
question. Everyone else here does it this way, and I think you should
do that too. Not doing that effectively slows down the review. For
example, if you think that the rationale for a request in a review is
too weak, point out precisely why you think that is the case.
Also, if I raise a design issue in a review, that's as much as a review
comment as any other comment about a particular piece of code. I don't
bring up these things because I like posting lengthy emails. I expect
you to discuss such issues. AFAIK this project is consensus-driven, and
without the discussions we don't get the consensus necessary to approve
a patch.
Torvald