Is reading and writing process.env values synchronous?

Question

Reading and writing environment variables in Node.js is done using the process.env object.

For instance:

• process.env.foo evaluates to the env var foo
• process.env.bar = 'blah' sets the value of the env var bar to blah
• delete process.env.baz deletes the environment variable baz

From trial and error, and the lack of a callback, I assume that these actions are synchronous, but I found no reference to it process.env documentation.

Is env var access synchronous or asynchronous in Node.js?

---

Addendum: Why I believe this question to be non-trivial

Following the comments: Reading and writing the environment variables might mean that the process needs to communicate with the operating system, or perform some sort of blocking I/O operations.

Therefore, it makes sense to ask whether the environment variables are stored as a local object in memory without any synchronization, or otherwise sent to the operating system in a blocking manner.

Moreover, implementation may vary between operating systems and the official documentation lacks any promise to a non-blocking operation.

Answer 1

I think the "synchronous"/"asynchronous" may be a bit misleading.

I guess the actual question is: Is reading from or writing to process.env expensive? Does it perform a blocking operation with the operating system?

The short answer is Yes, it can be expensive.

For more background info and how much it can impact some apps, see this GitHub issue. There it was already stated that the documentation should be updated to make it clear that accessing process.env is slow in 2015 but it hasn't happened yet.

You can actually see the implementation for process.env in the node.js source code where it's obvious that any access will call one of the functions defined from here onwards.

Note: At the time of writing, this was defined in node.cc in a more straight-forward way. The links above still point to the old implementation. Newer versions of node have process.env implemented in a separate file node_env_var.cc which can be found here, but it has more encapsulation, making it harder to follow for the purpose of this explanation.

Depending on the platform, this may have more or less of an impact.

It becomes most obvious on Windows, because there you can view a process' current environment from the outside (while in Linux, the /proc/.../environ file will retain its original contents when the environment was changed with setenv).

For example:

node -e "process.env.TEST = '123'; setInterval(() => {}, 1000);";

This will start a node process which creates a TEST environment variable in the current process' environment and then wait forever.

Now we can open a tool like Process Explorer or Process Hacker and look at the environment of the node process:

And lo and behold, the variable is there. This proves in another way that writing to process.env does in fact access the operating system.

Also, because the object actually queries all data from the OS, it means that it even behaves different than a normal object. Again, Windows example (because it's most quirky):

• Windows matches environment variables case-insensitive.

    > process.env.TEST = '123'
    '123'
    > process.env.tEsT
    '123'
  

• Windows has hidden environment variables starting with = which cannot be changed through normal means and which are not enumerated. node.js replicates these semantics. The =X: variables in particular represent the current directory in specific drives (yes, Windows stores them per drive).

    > Object.keys(process.env).filter(k => k === '=Z:')
    []
    > process.env['=Z:']
    'Z:\\'
    > process.env['=Z:'] = 'Z:\\Temp'
    'Z:\\Temp'
    > process.env['=Z:']
    'Z:\\'
    > process.chdir('Z:\\Temp')
    undefined
    > process.env['=Z:']
    'Z:\\Temp'
  

Now, somebody might think (similar to what was proposed in the GitHub issue that I linked) that node.js should just cache process.env in an actual object, and for child process creation read the environment from the cached object. This is not advisible for the following reasons:

• They would need to copy the semantics of the underlying platform and reimplement them. As you can see in the above example for Windows, this would at some point end up in intercepting chdir and trying to automatically update the relevant =X: variable of the affected drive (and then it wouldn't work if a native plugin would change the current directory), or access the OS only for some variables, and therein lies madness and huge potentional for obscure bugs.
• This would break applications which read a process' environment from the outside (like Process Explorer), as they would see incorrect values.
• This would create inconsistencies if a native module would access the environment variables in its own from C++ code, because they would now have a different state than the cached object.
• This would cause childprocesses to not inherit the correct variables if the child process were started by a native module (for the same reason as above).

This should also explain why it is a bad idea to do process.env = JSON.parse(JSON.stringify(process.env)) in your code. For one, it would break case-insensitivity on Windows (and you can't possibly know what modules which some other module requires may depend on that), and apart from that it would of course cause tons of other problems as described above.