Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Jul 2007 13:51:11 -0500 (CDT)
From:      "Sean C. Farley" <scf@FreeBSD.org>
To:        Andrey Chernov <ache@nagual.pp.ru>
Cc:        freebsd-current <freebsd-current@FreeBSD.org>, Robert Watson <rwatson@FreeBSD.org>, Michal Mertl <mime@traveller.cz>
Subject:   Re: Environment handling broken in /bin/sh with changes to {get,set,put}env()
Message-ID:  <20070707133102.C14065@thor.farley.org>
In-Reply-To: <20070707131359.GB96605@nagual.pp.ru>
References:  <20070704173905.T67251@fledge.watson.org> <20070704121316.A77978@thor.farley.org> <20070704180000.GA34042@nagual.pp.ru> <20070704144159.X77978@thor.farley.org> <20070704195939.GA35302@nagual.pp.ru> <20070704235630.GA42227@nagual.pp.ru> <20070704215154.O77978@thor.farley.org> <20070705115816.GA50506@nagual.pp.ru> <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 7 Jul 2007, Andrey Chernov wrote:

> On Sat, Jul 07, 2007 at 05:09:00PM +0400, Andrey Chernov wrote:
>> Well, I see. You try to keep envVars[] between environ switch by that
>> way.

My intention is have all allocated memory tracked.  This way all memory
can be freed explicitly.  In turn, this allows for easier debugging of
*env() functions or any programmers using these functions.

Besides, I wrote the code on July 4th.  It was born to be free().  :)

>> But it still look complicated and probably gains nothing. I.e. will
>> be much _faster_ just free envVars[] (but not variables themselfs)
>> and allow build_env() to calloc() new array for envVars and fills it
>> from new environ. It is surely faster than calling setenv() for each
>> variable just for sake of keepeng once allocated envVars[].

I feel the change is easy to follow since it is reusing existing
functions.  Compared to other sections of code, this part is easy.  :)

I agree that it would be faster for a subset of an existing environ.  On
the other hand, in the case of emptying the environment, my method would
be faster since no deallocation, allocation nor setenv() calls would be
called assuming putenv() was not used.  I could try a few tests to see
what is faster in which case, but I do not think environ changes happen
often enough to make speed a factor.

>> Moreover, environ switch commonly used to switch from large environ
>> to smaller one (or to empty one), so the rest of old envVars[] array
>> would keep unneccessary allocation.

If the new environ only contains a subset with the same values of an
existing environ, then the total bytes will not increase.  No
(de)allocations functions would be called.  freeing envVars and starting
anew will result in memory allocations for envVars and every variable
within the new environ.

> BTW, if you just free(envVars) when environ switch is detected, there
> is no needs to __remove_putenv() (big slowdown) in the __clean_env()
> too.

I just changed it to only call __remove_putenv() during a merge.

Sean
-- 
scf@FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070707133102.C14065>