Re-sending to core-libs-dev
On 13/05/2017 5:56 PM, David Holmes wrote:
Hi Dalibor,
On 12/05/2017 11:28 PM, dalibor topic wrote:
On 11.05.2017 18:29, Cédric Champeau wrote:
Unfortunately, they are not safely mutable in multi-threaded
programs on many operating system/libc combinations.
But the problem is less about mutating, that it is about reading: the VM
returns wrong values at some point, because it _assumes_ that the
environment variables are not mutated.
Right. Assuming that another thread could be simultaneously writing to
the same data structure holding environment variables (char **), reading
itself becomes problematic at such points in time, as you might read a
temporarily corrupted data structure.
I guess the question underneath is if there is a safe point in time when
reading the data could be preformed and no concurrent write from JNI
code corrupting the data when it's partially read is possible.
I'm afraid no such safe point guarantee exists at all - even for the
initial reading of the process environment on the first call to System
getenv(). There could always potentially be some JNI, or other native
in-process code, mutating the environ char** at the same time as we
first read it in the JVM.
But we're not trying to protect against random concurrent updates in the
current scenario, things are more structured:
- request comes in with data that says to update certain env vars
- JNI code updates the env vars
- the daemon's java code (currently) causes the System.getenv map to be
updated
- the "client" code is executed and reads the env var and sees the right
value
There would have to be a caveat on System.getenv(true) if we went that
path, that it is up to the user to ensure it is called in as safe a
manner as possible having regard to any concurrent updates in their
application code and how the environment is managed on a given platform.
Cheers,
David
-----
cheers,
dalibor topic
