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 vstinner
Recipients docs@python, vstinner
Date 2018-11-19.11:50:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Many developers only discover that a Python function/module is not thread safe because they have a bug in production...

Some examples:

* bpo-7672: ssl
* bpo-8865: select.poll is not thread safe
* bpo-539175, bpo-21216: socket.gethostbyname()
* bpo-7980: time.strptime()
* bpo-6647: warnings.catch_warnings()
* bpo-11077, bpo-33479: Tkinter
* bpo-1336, bpo-19809: subprocess on Python 2
* bpo-15329: deque
* bpo-35275: os.umask()

Hopefully, sometimes it was possible to fix it:

* bpo-3139: bytearray, buffer protocol
* bpo-28969: @functools.lru_cache
* bpo-21291: subprocess.Popen.wait()

In the asyncio documentation, I explicitly documented that, by design, most classes are not thread-safe. For example, asyncio.Lock() is *NOT* thread-safe:

Maybe we should start to use a standard way to describe "thread safety". See "POSIX Safety Concepts" of the GNU libc:

Example with setlocale, "MT-Unsafe":


My own (incomplete) list of "process-wide states":
Date User Action Args
2018-11-19 11:50:11vstinnersetrecipients: + vstinner, docs@python
2018-11-19 11:50:08vstinnersetmessageid: <>
2018-11-19 11:50:08vstinnerlinkissue35276 messages
2018-11-19 11:50:08vstinnercreate