Re: libgcrypt brain dead?
On Sat, 20 Mar 2010, Florian Weimer wrote:
> * Henrique de Moraes Holschuh:
>
> > 2. Must be thread-safe, and fully reentrant both at the function and at
> > the _library_ level;
>
> This does not include the async-signal-safe property, right? I'm also
> not sure if the function needs to be reentrant within the same thread
> (depending on what it does, of course).
I knew I forgot something... AFAIK it needs to be reentrant within the same
thread in the worst cases (like: being indirectly linked through an NSS
module to an application that uses the library directly or indirectly), and
I do think this probably means it has to be signal-safe as well. Which is a
major annoyance.
The worst possible use case I know of is:
1. used by the application in one mode
2. used by some library the application uses, in another mode
3. used by NSS.
> > 4. Must not change any global attributes of the process or of any other
> > libraries it uses;
>
> Strictly speaking, this precludes creating child processes, which is
> rather drastic. 8-(
Well, I'd say the library can't create child processes or other threads in a
way that is unexpected by the application, and it likely needs to be able to
do so through callbacks. It gets nasty very very fast, and you probably
cannot do that for something that might end up used in NSS or other such
sick schemes that do surprise shadow linking of tons of crap to an
application.
NSS really should run its heavyweight stuff in a separate process started
beforehand by the system, and talk to glibc through some sort of
thread-safe, signal-safe IPC.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: