New submission from STINNER Victor <vstin...@redhat.com>:
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: https://docs.python.org/dev/library/asyncio-sync.html#asyncio.Lock Maybe we should start to use a standard way to describe "thread safety". See "POSIX Safety Concepts" of the GNU libc: https://www.gnu.org/software/libc/manual/html_node/POSIX-Safety-Concepts.html#POSIX-Safety-Concepts Example with setlocale, "MT-Unsafe": https://www.gnu.org/software/libc/manual/html_node/Setting-the-Locale.html -- My own (incomplete) list of "process-wide states": https://vstinner.readthedocs.io/threads.html#process-wide ---------- assignee: docs@python components: Documentation messages: 330093 nosy: docs@python, vstinner priority: normal severity: normal status: open title: Document thread safety versions: Python 3.8 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35276> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
