This is the mail archive of the 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] New condvar implementation that provides stronger ordering guarantees.

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.

> 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
> avoidance.

I think the point here is that they may be inlined and we want to
leave it up to the compiler to decide.

If we put them in their own file and compile that into an object file,
we won't have a chance to inline them until we get LTO.

If all the functions had been marked static always inline then I would
agree it would make sense for us to place them into a header, since
they are the equivalent of macros.

However, in this grey zone where Torvald has static functions which
may or may not be inlined (you want to leave it up to the compiler
to decide) it seems to me like using a *.c file and including it
from other C files seems like a reasonable way to structure this.



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