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
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.
Stony Brook Software
the reply, fubar => ix.netcom
> [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.?