[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87turrvjl2.fsf@oldenburg2.str.redhat.com>
Date: Fri, 08 Jan 2021 10:55:37 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Keith Packard <keithp@...thp.com>
Cc: libc-coord@...ts.openwall.com
Subject: Re: Future directions for *_r functions
* Keith Packard:
> Florian Weimer <fweimer@...hat.com> 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
applications.
> 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.
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , 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.
