5 ms·

From the way I read the python source code[1] implementation of the Environment class, I think python is also affected. 1. https://github.com

From the way I read the python source code[1] implementation of the Environment class, I think python is also affected. 1. https://github.com/python/cpython/blob/master/Lib/os.py#L664 https://github.com/python/cpython/blob/master/Lib/os.py#L664

poizan42 10y ago
Uhh that just looks the key up in a python dict in data. That itself is thread safe. But if you read the code more carefully you would see that the _Environ class is constructed from _createenviron[1], where it expects a dict-like global called environ to already exist, which it's just a wrapper over. The pre-existing environ is then overwritten by the _Environ object[2]. The original os.environ is created somewhere else entirely. This file just sets it to an empty dict if it isn't already set[3]. os.environ is actually set in native code, here [4]. It is created by the createenviron function[5]. Now what you should note is that this is actually created as a python dict, and the native environment is copied into it. So a python program usually never touches the native environment after initialization. This is fine as long as only python functions are used to start child processes as these converts the environment into a native environment block and gives it as the envp pointer to the exec/spawn functions. [1]: https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca294122cced3f63373e9b/Lib/os.py#L723 https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca2... [2]: https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca294122cced3f63373e9b/Lib/os.py#L754 https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca2... [3]: https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca294122cced3f63373e9b/Lib/os.py#L516 https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca2... [4]: https://github.com/python/cpython/blob/b9e40ed1bcce127893e40dd355087cda7187ac27/Modules/posixmodule.c#L12953 https://github.com/python/cpython/blob/b9e40ed1bcce127893e40... [5]: https://github.com/python/cpython/blob/b9e40ed1bcce127893e40dd355087cda7187ac27/Modules/posixmodule.c#L1223 https://github.com/python/cpython/blob/b9e40ed1bcce127893e40...
- JdeBP 10y ago
  The C runtime libraries on various platforms do much the same. The environment array is not provided as such by the operating system, so the C runtime libraries set up their internal instances of the environment array, and sometimes of the entire environment. As you say, everything is easy as long as one always sticks to the C library functions for accessing/using the environment, and as long as one does not mix multiple C runtime libraries with one another within a single process (or indeed multiple runtime libraries from multiple languages).

poizan42 10y ago

Uhh that just looks the key up in a python dict in data. That itself is thread safe. But if you read the code more carefully you would see that the _Environ class is constructed from _createenviron[1], where it expects a dict-like global called environ to already exist, which it's just a wrapper over. The pre-existing environ is then overwritten by the _Environ object[2]. The original os.environ is created somewhere else entirely. This file just sets it to an empty dict if it isn't already set[3]. os.environ is actually set in native code, here [4]. It is created by the createenviron function[5]. Now what you should note is that this is actually created as a python dict, and the native environment is copied into it. So a python program usually never touches the native environment after initialization. This is fine as long as only python functions are used to start child processes as these converts the environment into a native environment block and gives it as the envp pointer to the exec/spawn functions. [1]: https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca294122cced3f63373e9b/Lib/os.py#L723 https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca2... [2]: https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca294122cced3f63373e9b/Lib/os.py#L754 https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca2... [3]: https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca294122cced3f63373e9b/Lib/os.py#L516 https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca2... [4]: https://github.com/python/cpython/blob/b9e40ed1bcce127893e40dd355087cda7187ac27/Modules/posixmodule.c#L12953 https://github.com/python/cpython/blob/b9e40ed1bcce127893e40... [5]: https://github.com/python/cpython/blob/b9e40ed1bcce127893e40dd355087cda7187ac27/Modules/posixmodule.c#L1223 https://github.com/python/cpython/blob/b9e40ed1bcce127893e40...

JdeBP 10y ago
The C runtime libraries on various platforms do much the same. The environment array is not provided as such by the operating system, so the C runtime libraries set up their internal instances of the environment array, and sometimes of the entire environment. As you say, everything is easy as long as one always sticks to the C library functions for accessing/using the environment, and as long as one does not mix multiple C runtime libraries with one another within a single process (or indeed multiple runtime libraries from multiple languages).