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: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 30 May 2013 12:40:22 +0530
- 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:
> 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.
As Carlos pointed out, the environment variables are read only once
during startup, so at that point threading doesn't come into the
picture at all. However, there could be a scenario where a thread in
the process is setting the environment variable and another thread
does a fork + exec. With this combination, there is a possibility
that the exec'd process has an invalid environment variable value.
Speaking of which, it doesn't look like the environment variable write
lock is reset at fork. There may be a chance at a deadlock if the
process forked in the middle of a setenv and the child tried to
setenv. But I digress...
Siddhesh