Getting a live view of environment variables (Gradle and JDK 9)
dalibor.topic at oracle.com
Tue May 16 10:00:31 UTC 2017
Thanks for the explanation, David. That doesn't sound much more risky than what we already do today in getenv.
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214<tel:+494089091214> | Mobile: +491737185961
ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
> On 15. May 2017, at 07:14, David Holmes <david.holmes at oracle.com> wrote:
> 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
>> - the "client" code is executed and reads the env var and sees the right
>> 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.
>>> dalibor topic
More information about the core-libs-dev