Commit Graph

3 Commits

Author SHA1 Message Date
bde
99aef07680 Fixed the type of dllockinit() (const unpoisoning).
Use long lines instead of lines split with backslash-newline in synopsis.
My synopsis checker doesn't understand backslash-newline.
2000-01-05 19:04:55 +00:00
jdp
363b7bd537 Work around an assert failure in the dynamic linker's default thread
locking functions.  If an application loads a shared object with
dlopen() and the shared object has an init function which requires
lazy binding, then _rtld_bind is called when the thread is already
inside the dynamic linker.  This leads to a recursive acquisition
of the lock, which I was not expecting -- hence the assert failure.

This work-around makes the default locking functions handle recursive
locking.  It is NOT the correct fix -- that should be implemented
at the generic locking level rather than in the default locking
functions.  I will implement the correct fix in a future commit.

Since the dllockinit() interface will likely need to change, warn
about that in both the man page and the header file.
1999-12-28 04:38:17 +00:00
jdp
52ec4df9e8 Add a new function dllockinit() for registering thread locking
functions to be used by the dynamic linker.  This can be called by
threads packages at start-up time.  I will add the call to libc_r
soon.

Also add a default locking method that is used up until dllockinit()
is called.  The default method works by blocking SIGVTALRM, SIGPROF,
and SIGALRM in critical sections.  It is based on the observation
that most user-space threads packages implement thread preemption
with one of these signals (usually SIGVTALRM).

The dynamic linker has never been reentrant, but it became less
reentrant in revision 1.34 of "src/libexec/rtld-elf/rtld.c".
Starting with that revision, multiple threads each doing lazy
binding could interfere with each other.  The usual symptom was
that a symbol was falsely reported as undefined at start-up time.
It was rare but not unseen.  This commit fixes it.
1999-12-27 04:44:04 +00:00