Re: Consensus: Tuning runtime behaviour with environment variables.

[KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>]

On Wed, May 29, 2013 at 6:01 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 05/29/2013 03:15 PM, 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.
>
> Thank you for commenting.
>
> For the record, are you for or against the use of environment variables
> to tune runtime library behaviour (assume that they are thread safe)?

I'm not against at all if it doesn't break thread safety. I only would like to
point out developers need some attention.



> At present we plan to read the env vars in the dynamic loader before
> the application is started. The dynamic loader already walks the env
> var list to process it's own env vars and we have patches that hook
> into this (minimizes any performance impact since the loader is already
> doing a walk of the list).
>
> I've added an explicit line in the specification to point out that the
> API for tunables, and the processing of env vars must be thread safe.
>
> I've also added text to note that processing of env vars to tune
> runtime behaviour happens only once at startup before entering main.
>
> See:
> http://sourceware.org/glibc/wiki/TuningLibraryRuntimeBehavior

Thanks! That's clear to me.