Getting a live view of environment variables (Gradle and JDK 9)

David Holmes david.holmes at oracle.com
Mon May 15 05:14:39 UTC 2017


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


More information about the core-libs-dev mailing list