glibc2: reentrancy, thread-safety, signal-safety

glibc2: reentrancy, thread-safety, signal-safety

Post by Peter Kovac » Tue, 03 Nov 1998 04:00:00



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

 
 
 

glibc2: reentrancy, thread-safety, signal-safety

Post by Ian D Romani » Tue, 03 Nov 1998 04:00:00



>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

 
 
 

1. LinuxThreads and thread-safety, re-entrancy, async-safety!

[Repost from other newsgroup]

Hi all.

Need advice!

My company takes on to porting a very sensitive library to Linux (RedHat

7.0, glibc 2.2.9). The library uses POSIX threads heavily.
On Linux, at this time, LinuxThreads seems to be a very mature package
and looks like being the right choice (and the only good one). However,
we have come upon some documentation (not very up-to-date but
anyways...) on the net saying that glibc is not fully thread-safe
(LinuxThreads package README says that too). Also, the documentation
warns about the non re-entrancy of other libraries in the system and
about possible problems when mixing with libraries like svgalib that
uses SIGUSR signals that LinuxThreads use too.

So: what is your opinion? Stick with LinuxThreads or look after a
user-level threads package? We were thinking that a user-level thread
package would alleviate some of the problems.

What is the latest news in kernel re-entrancy (2.2.x kernels)? Any
links, points, etc.?

Thanks++

2. no route to host problem when pinging a NIC

3. signals and thread safety

4. Replacing finger information

5. Linux libraries and thread-safety!!!

6. 2.4.21pre7 make raw devices appear in devfs

7. A question on thread-safety

8. Building kernel to solve network problems...

9. Thread-safety of X11-app

10. atomicity / thread-safety: PF_PACKET socket and tap file descriptor

11. How to check thread-safety of code on routine usage

12. Thread safety confusion Pl help

13. STL thread safety ?