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: OndÅej BÃlka <neleai at seznam dot cz>
- To: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 29 May 2013 23:59:55 +0200
- Subject: Re: Consensus: Tuning runtime behaviour with environment variables.
- References: <51A58A92 dot 4050508 at redhat dot com> <51A653DC dot 4040702 at gmail dot com>
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).