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

[Andrew Doran <ad%homeworld.netbsd.org@localhost>]

On Thu, Nov 18, 2010 at 03:59:39PM +0000, Matthias Scheler wrote:
> 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.

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

Ok this is good news, thanks.

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

The application is free to shoot itself in the foot any way it likes,
we don't have to worry abut that.  As long as the getenv/setenv internals
don't shoot anybody in the foot when operated concurrently, then we can
can handle the concurrency any way we like.  Obviously the conservative
way to do this is use a big lock around the component, as we have now.
A simple unsorted array can be an interesting basis for doing things
locklessly provided you constrain some of its properties. :-)