glibc2: reentrancy, thread-safety, signal-safety

[Peter Kovacs]

I have heard that glibc2 is close to thread-safe. Does anyone know how
thread thread safety is implemented. Does thread-safety mean signal-safety
that is: I can use --say-- malloc() both in the main process-flow code and
in signal handlers. I suppose it would fairly simply to enforce
thread-safety by using library owned mutexes or critical sections. But this
would preclude signal safety because of potential deadlocks.

By the same token, does anyone know how reentrancy relates to thread-safety
and signal-safety.

Thanks.

Peter

[Ian D Romanick]

"Peter Kovacs" <peter....@sysdata.siemens.hu> writes:

>that is: I can use --say-- malloc() both in the main process-flow code and
>in signal handlers. I suppose it would fairly simply to enforce
>thread-safety by using library owned mutexes or critical sections. But this
>would preclude signal safety because of potential deadlocks.

That is 100% true. I strongly suspect that many functions that modify
internal state (like malloc) are not signal safe, due to possible deadlock.
I think that the idea is that you won't do a lot inside the signal handler.
POSIX actually lists a number of things (like mutex operations) that cannot
be done within a signal handler. It's just like there are a lot of things
that you can't do in most OSes in an interrupt handler.
--
"You must understand...that there are two ways of fighting: by
law or by force. The first way is natural to man, and the
second to beasts. But as the first way often proves inadequate
one must have recourse in the second." -- Machiavelli, The Prince