Date: Tue, 05 Jan 2021 10:16:50 -0800 From: Keith Packard <keithp@...thp.com> To: Florian Weimer <fweimer@...hat.com>, libc-coord@...ts.openwall.com Subject: Re: Future directions for *_r functions 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. 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? -- -keith Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
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.