[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zh1n5jvx.fsf@keithp.com>
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.
