This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] New condvar implementation that provides stronger ordering guarantees.
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>, Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, David Miller <davem at davemloft dot net>, Darren Hart <dvhart at infradead dot org>
- Date: Wed, 15 Jun 2016 09:07:22 +0200
- Subject: Re: [PATCH] New condvar implementation that provides stronger ordering guarantees.
- Authentication-results: sourceware.org; auth=none
- References: <1464268895 dot 17104 dot 14 dot camel at localhost dot localdomain> <9ba4528e-6c48-f832-825a-bdc68c37eb47 at redhat dot com> <1465928107 dot 19633 dot 109 dot camel at localhost dot localdomain> <3a0380b8-d958-6af6-28ca-d228353d9ef8 at redhat dot com> <1465931244 dot 19633 dot 120 dot camel at localhost dot localdomain> <e6f9aa4d-c343-9285-5c75-da10362eb307 at redhat dot com> <199405ea-05d5-7dc7-ca60-06f3d7f9c32a at redhat dot com>
On 06/14/2016 10:40 PM, Carlos O'Donell wrote:
On 06/14/2016 04:14 PM, Florian Weimer wrote:
I believe pthread_cond_common.c is similar. It doesn't use the
preprocessor to alter any behavior, but just uses C to provide
commonly used functionality. It doesn't provide any functions that
are just declarations, so something a C header would typically do.
We already have header files which contain inline functions,
something that is quite natural.
These are usually marked 'always inline' though aren't they? They
are basically equivalent to enhanced macros.
They are usually marked inline. But there are exceptions, e.g.
It's also not completely clear to me if other case just use âstatic
inlineâ to suppress the unused function warning.
If the functions are not expected to be inlined, you should put them
in their own file, and declare them with attribute_hidden for PLT
I think the point here is that they may be inlined and we want to
leave it up to the compiler to decide.
But the compiler cannot make well-informed decisions because it will
assume that static functions are local to the current translation, when
it fact they are not (from the perspective of the cost in terms of code
size of not inlining them).
Anyway, I still prefer the current split over putting everything into a
single source file.