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 vstinner
Date 2020-03-27.15:51:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1585324297.97.0.65509955463.issue40089@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2020-03-27 15:51:38vstinnersetrecipients: + vstinner
2020-03-27 15:51:37vstinnersetmessageid: <1585324297.97.0.65509955463.issue40089@roundup.psfhosted.org>
2020-03-27 15:51:37vstinnerlinkissue40089 messages
2020-03-27 15:51:37vstinnercreate