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 <> 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
* 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