Thanks for the explanation, David. That doesn't sound much more risky than what we already do today in getenv.
Cheers, Dalibor -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214<tel:+494089091214> | Mobile: +491737185961 <tel:+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.hol...@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 >> 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
