This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [COMMITTED PATCH] Split timed-wait functions out of nptl/lowlevellock.c.
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Wed, 10 Jun 2015 13:18:34 -0700 (PDT)
- Subject: Re: [COMMITTED PATCH] Split timed-wait functions out of nptl/lowlevellock.c.
- Authentication-results: sourceware.org; auth=none
- References: <20150526221729 dot 7B7762C39FC at topped-with-meat dot com> <1432716709 dot 30849 dot 46 dot camel at triegel dot csb> <20150610001338 dot 548F52C3BE6 at topped-with-meat dot com> <1433940369 dot 10071 dot 73 dot camel at triegel dot csb>
> In general, I agree. Nonetheless, in the particular case of
> synchronization code, I'd argue that we're likely doing something wrong
> if we need to specialize, say, Linux pthread_cond_signal, while keeping
> all other Linux pthread_cond_* functions unchanged. Functions that
> synchronize with each other are often much more dependent on each other
> than in sequential code, so the more variations there are the more
> complex it gets.
I understand the concern.
> Your patch added arch-specific variants on Linux, which isn't a bug as
> you correctly say, but it goes in the opposite direction of where we
> want to be at, I believe.
Not really. I did not actually change the status quo for x86 and
sparc32 (the machines that have their own lowlevellock.[cS]). I had to
add dummy files to let them stay as they are. I didn't touch them
further than that since I wanted to minimize perturbation in that one
change. But the change makes it possible to remove some existing
duplication, such as __lll_timedwait_tid in sparc32/lowlevellock.c,
which is a verbatim copy of the generic code that was made in the first
place only because too many functions were put into this one file. I
didn't do that sparc32 cleanup myself because I don't want to deal with
testing or possibly breaking the sparc build myself.
> Another thing I have observed is that having variants of files available
> seems to invite variant-specific changes that could actually have been
> applied or fixed generically. Maybe that's something we can counter by
> paying more attention to this during review -- but not having separate
> files in the first place is a bigger hurdle :)
Certainly review is the best time to catch these.