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

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

Post by Billy Bob Jameso » Mon, 09 Apr 2001 01:17:49



[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++

 
 
 

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

Post by Norman Blac » Wed, 11 Apr 2001 05:14:04


About re-entrancy. Many of the historical "Unix" API's are not ren-entrant.
This is because threads are a newer concept and the API's are very old.
Re-entrant API's exist for the affected calls, and most are POSIX standard.
For example readdir has a re-entrant version called readdir_r. The MAN pages
will likely comment on re-entrancy if applicable and also list the
re-entrant calls. It is your responsibility to make sure your threaded code
is using re-entrant API calls.

LinuxThreads does not use SIGUSR on any 2.2 and later kernel. I cannot
comment on anything older since I have no experience with this. LinuxThreads
uses the first two "realtime" signals. In fact LinuxThreads hooks the glibc
call(s) and "alters" the return value of SIGRTMIN to reflect the signals it
consumes.

About re-entrancy of "other" libraries on the system. This is just a fact of
life. Due to history much has not been written with threads in mind. For
example GTK+ is not re-entrant.

About kernel re-entrancy. It is getting better as time passes by. This is of
no concern for you, since the kernel protects itself, and any lack of
re-entrancy affects forked and threaded applications equally.

--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom



Quote:> [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++


 
 
 

1. glibc2: reentrancy, thread-safety, signal-safety

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

2. umount nfs only

3. Linux libraries and thread-safety!!!

4. Remote ELKS kernel debugging

5. A question on thread-safety

6. IP watching between 2 Hosts

7. Thread-safety of X11-app

8. Soundcard- Ess1868

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

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

11. ext2fs sync vs. async speed and safety

12. Thread safety confusion Pl help

13. STL thread safety ?