Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 08 Jan 2021 10:55:37 +0100
From: Florian Weimer <>
To: Keith Packard <>
Subject: Re: Future directions for *_r functions

* Keith Packard:

> Florian Weimer <> writes:
>> Personally, I'm leaning towards the first option (thread-safe non-_r
>> variants plus dup*ent and free*ent helpers).  That's largely based on my
>> exposure to the current glibc implementation and the interfaces it
>> provides to programmers.
> Agreed. Making the 'normal' libc API thread safe has huge benefits to
> existing applications which will not need to be rewritten to take
> advantage of these fixes. I've implemented a mixture of atomic
> operations, locking and thread-local values for some of the _r functions
> in picolibc, but that doesn't include the huge range of network-facing
> functions found in larger libraries.

For glibc, we would still add symbol versions once things are thread
safe because conforming programs can observe the global state sharing
(e.g., by using a mutex to coordinate access from different threads).

I want to avoid a situation where we end up with bugs in old
applications (e.g., use-after-free after a thread calling gehostbyname
exited), but can only fix them by disabling per-thread state for all

> The only problem with thread-local values is that when exposed in the
> API (such as withh lgamma_r's signgam), they are not ABI compatible. I
> *think* symbol versioning could help here?

Historically, I think we had a few such transitions involving global
data objects in glibc.  This was all before my time.

Two separate strategies where used:

* Store a pointer in TLS space that points to the global data object on
  the main thread, and further TLS data on other threads.  This is the
  approach that was used for _res.

* Keep updating the global data object, in addition to the non-shared
  data object.  I think this is what localtime_r does.

I don't think either approach applies to the *_r functions.

Red Hat GmbH, , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.