New submission from STINNER Victor <vstin...@python.org>:
Using a lock after fork() is unsafe and can crash. Example of a crash in logging after a fork on AIX: https://bugs.python.org/issue40068#msg365028 This problem is explained in length in bpo-6721: "Locks in the standard library should be sanitized on fork". The threading module registers an "at fork" callback: Thread._reset_internal_locks() is called to reset self._started (threading.Event) and self._tstate_lock. The current implementation creates new Python lock objects and forgets about the old ones. I propose to add a new _at_fork_reinit() method to Python lock objects which reinitializes the native lock internally without having to create a new Python object. Currently, my implementation basically creates a new native lock object and forgets about the old new (don't call PyThread_free_lock()). Tomorrow, we can imagine a more efficient impementation using platform specific function to handle this case without having to forget about the old lock. ---------- components: Library (Lib) messages: 365157 nosy: vstinner priority: normal severity: normal status: open title: Add _at_fork_reinit() method to locks versions: Python 3.9 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40089> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
