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.