Re: [patch] Re: dlopen() and dlclose() are not MT-safe? YES, esp. for libthr
- From: Kazuaki Oda <kaakun@xxxxxxxxxxxxx>
- Date: Fri, 24 Mar 2006 20:54:34 +0900
Kostik Belousov wrote:
I did understand the purpose of the thread mask code in
libexec/rtld/rtld_lock.c, or, more precisely, the condition where this code
works (for the context, see the mails with same subject on freebsd-hackers).
Look, that code assumes that blocking async signals would stop thread
scheduler from doing preemption of the current thread. This works
for libc_r, but fails in libpthread and libthr cases. libpthread provides
implementation of the locks for rtld. But libthr does not !
As result, rtld exhibit races when used with libthr. In other words,
libthr needs code to do proper locking.
Do you agree ? Does somebody already planned to do this work ?
Best regards,
Kostik Belousov
I'm a bit confused. Do you mean the following?
* The current implementation of rtld has a problem both with
libpthread and libthr. It works only with libc_r.
* In libpthread case, the problem goes away if we modify rtld code.
* In libthr case, in addition to above, we must modify libthr code to
provide implementation of the locks for rtld.
right?
--
Kazuaki Oda
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- References:
- dlopen() and dlclose() are not MT-safe?
- From: Kazuaki Oda
- Re: dlopen() and dlclose() are not MT-safe?
- From: Kostik Belousov
- Re: dlopen() and dlclose() are not MT-safe?
- From: Kostik Belousov
- Re: dlopen() and dlclose() are not MT-safe?
- From: Kazuaki Oda
- [patch] Re: dlopen() and dlclose() are not MT-safe?
- From: Kostik Belousov
- Re: [patch] Re: dlopen() and dlclose() are not MT-safe? YES, esp. for libthr
- From: Kostik Belousov
- dlopen() and dlclose() are not MT-safe?
- Prev by Date: Re: copy paste in freebsd
- Next by Date: Exposing a file's creation time via find(1)
- Previous by thread: Re: [patch] Re: dlopen() and dlclose() are not MT-safe? YES, esp. for libthr
- Next by thread: Re: [patch] Re: dlopen() and dlclose() are not MT-safe? YES, esp. for libthr
- Index(es):
Relevant Pages
- Re: [patch] Re: dlopen() and dlclose() are not MT-safe? YES, esp. for libthr
... but fails in libpthread and libthr cases. ... rtld exhibit races
when used with libthr. ... libthr needs code to do proper locking. ... (freebsd-hackers) - Re: [patch] Re: dlopen() and dlclose() are not MT-safe? YES, esp. for libthr
... but fails in libpthread and libthr cases. ... rtld exhibit races
when used with libthr. ... provide implementation of the locks for rtld. ... (freebsd-hackers) - Re: libc_r is deprecated
... In the libthr vs. libpthread ... it could well be that libpthread reduces
kernel lock ... (freebsd-arch) - Re: libc_r is deprecated
... libpthread, and libthr is way behind. ... how libpthread doesn't handle
SMP scheduling well either. ... especially embarresing because libc_r is a single process,
... (freebsd-arch) - Re: libc_r is deprecated
... libpthread, and libthr is way behind. ... how libpthread doesn't handle
SMP scheduling well either. ... especially embarresing because libc_r is a single process,
... (freebsd-arch)