This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gregory.p.smith
Recipients docs@python, gregory.p.smith
Date 2020-01-18.00:36:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
The underlying API calls made by os.putenv() and os.environ[name] = value syntax are not thread safe on POSIX systems.  POSIX _does not have_ any thread safe way to access the process global environment.

In a pure Python program, the GIL prevents this from being an issue.  But when embedded in a C/C++ program or using extension modules that launch their own threads from C, those threads could also make the invalid assumption that they can safely _read_ the environment.  Which is a race condition when a Python thread is doing a putenv() at the same time.

We should document the danger.

CPython's os module snapshots a copy of the environment into a dict at import time (during CPython startup).  But os.environ[] assignment and os.putenv() modify the actual process global environment in addition to updating this dict.  (If an embedded interpreter is launched from a process with other threads already running, even that initial environment reading could be unsafe if the larger application has a thread that wrongly assumes it has exclusive environment access)

For people modifying os.environ so that the change is visible to child processes, we can recommend using the env= parameter on subprocess API calls to supply a new environment.

A broader issue of should we be modifying the process global environment state at all from os.putenv() and os.environ[] assignment still exists.  I'll track that in another issue (to be opened).
Date User Action Args
2020-01-18 00:36:08gregory.p.smithsetrecipients: + gregory.p.smith, docs@python
2020-01-18 00:36:08gregory.p.smithsetmessageid: <>
2020-01-18 00:36:07gregory.p.smithlinkissue39375 messages
2020-01-18 00:36:07gregory.p.smithcreate