Re: Improved implementation of *env(3) functions in "libc"

[Matthias Scheler <tron%zhadum.org.uk@localhost>]

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
    changes.

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.

        Kind regards

-- 
Matthias Scheler                                  http://zhadum.org.uk/