[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Improved implementation of *env(3) functions in "libc"
On Thu, Nov 18, 2010 at 03:47:37PM +0000, Andrew Doran wrote:
> My concern with using a tree is that it makes a concurrent getenv() very
> hard to implement, and threaded programs like to make use of getenv().
1.) The reader-writer lock around the environment existed before my
2.) The tree is never used by getenv(3) or getenv_r(3). It is only
used by setenv(3), putenv(3) and unsetenv(3). The lock around
it could therefore be changed to be a mutex. But that wouldn't
solve the problem of the environment itself.
> Reader-writer locks don't scale on multi-core systems, and applications
> like this one (getenv) may give you single threaded or worse behaviour.
The data structure of the environment is fixed to be a simple unsorted
array which doesn't really allow concurrency. Unless you are willing
to accept that a program which uses *env(3) from multiple threads
needs to implement locking itself I don't think there is much else
you can do.
Matthias Scheler http://zhadum.org.uk/
Main Index |
Thread Index |