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: __libc_single_threaded design

On 07/10/19 2:23 pm, Florian Weimer wrote:
>> My understanding of the __libc (or __cxa on the other end) namespace is
>> that you'd want it if libstdc++ (and standard libraries, including glibc
>> itself) are the *only* intended users.  For a proper public symbol (i.e.
>> something we declare as widely available) it seems better to me to have
>> a name without the __libc prefix.
> We can make pthread_single_threaded_np.  That variable libstdc++ might
> even want to use directly, without a __ prefix.
> I do not feel *very* strongly about this.  But adding a second variable
> due to aesthetic considerations, possibly introducing bugs as a result,
> is not something what I like.
> We had this discussion several years ago about __secure_getenv.  Oh
> well.

I'm more inclined towards not having a __* name and having just one
variable (with a alias to skip the indirection) if it's
not necessary.

>>> The name is easy to change.  I believe we have support in the link
>>> editor so that linking to the public name also links against the private
>>> name.  If everything else fails, we could also have two variables which
>>> are updated at the same time.
>> Making a strong alias should be sufficient, but would we ever come
>> across a situation where the public and __libc_* name may assume
>> different meanings and hence need to exist as different variable names?
> Hmm.  We are in this situation with some of the math functions and
> signgam.  But I think there it works because nothing in the library
> calls gamma and lgamma spontaneously.  pthread_single_threaded_np would
> be different because pthread_create in strict POSIX mode would still
> assign to it.

OK, so do you agree that if we have just one pthread_single_threaded_np
and no other public aliases then we don't have any such issues?

I found the patch thread as well, so I can help with the patch review
for this.


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