tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Moving pthread_(cond|mutex) to libc
On Sat, 26 Jan 2013, Emmanuel Dreyfus wrote:
Alan Barrett <apb%cequrux.com@localhost> wrote:
Starting with NetBSD 6.0, libpthread is cursed with the NOLOAD
flag, which means it cannot be loaded by dlopen(). The problem
is that we can easily get to dlopen'able modules that do not
use pthreads, but are linked to libraries that are linked with
-lpthread. Such module cannot be loaded anymore in NetBSD 6.0.
Yes. And such modules would not work properly even if they
were allowed to be loaded.
Why would they?
I was referring to the current state of libc and libpthread, with
the hypothetical change of removing the NOLOAD flag to allow the
modules to be loaded, but without changing anything else. That
would not work properly, as has been described by other people
during previous rounds of discussions on this topic.
Also, please lets get the overall design clarified before
you write any code. I'd like to see a description of what
would happen if a program starts without pthreads, creates and
uses some condvars and mutexes, and then loads libpthread and
continues using the already-created condvars and mutexes.
The proposed patch address that problem, by having libc stubs
that fills mutexes and condvars fields.
I don't want to see a proposed patch, until after I see a design.
The questions that I would like to see answered include:
* What functions will be added or renamed or moved?
* What data structures will be added or changed?
* How will a mutex or condvar be initialised and used by libc?
* What are the performance impacts of the new libc code?
* Are there special values stored in the data structure to show that
it was initialised by a libc stub, as opposed to by libpthread?
* What happens when a mutex or condvar that is created
without libpthread continues to be used after libpthread is loaded?
* Does it also work if a mutex is locked at the time libpthread is
loaded?
* What happens when an application tries to create new threads after
loading libpthread?
With sufficient effort, I could figure all that out from the patch,
but I should not have to.
--apb (Alan Barrett)
Home |
Main Index |
Thread Index |
Old Index