This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus: Tuning runtime behaviour with environment variables.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha at sourceware dot org
- Date: Wed, 29 May 2013 18:17:16 -0400
- Subject: Re: Consensus: Tuning runtime behaviour with environment variables.
- References: <51A58A92 dot 4050508 at redhat dot com> <51A653DC dot 4040702 at gmail dot com> <20130529215955 dot GA31500 at domone dot kolej dot mff dot cuni dot cz>
On 05/29/2013 05:59 PM, OndÅej BÃlka wrote:
> On Wed, May 29, 2013 at 03:15:40PM -0400, KOSAKI Motohiro wrote:
>>> - User changeable environment variables that impact library runtime
>>> behaviour is dangerous.
>>>
>>> * Could you specifically point out what you find dangerous?
>>> I see no more danger than we already face when adding a new
>>> API or reviewing code changes. How is this different
>>> than all of the other work we do?
>>
>> Reading env variables may reduce multi thread safety level. I know
>> Siddhesh's patch doesn't have such issue. But I hope every developer
>> pay attention threading. i.e. In almost case, reading env var is not
>> generically safe after entering main(). As we already got reported,
>> at least, OpenOffice.org uses both setenv() and multi-threading. Even
>> though it is not unspecified from the standard POV, it's real.
>
> Other argument for Andi's vectorized getenv where env vars are cached.
>
> Needs comment that changing runtime behaviour by setting its setenv is
> not supported(Unless we add small performance penalty for each setenv).
No, using setenv will never change the behaviour once the process
is started. At that point your only option would be a new API that
exposes tunables in a thread-safe way with explicitly defined
semantics.
Does that make sense to you Ondrej?
Cheers,
Carlos.