Message365157
| 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:38 | vstinner | set | recipients:
+ vstinner |
| 2020年03月27日 15:51:37 | vstinner | set | messageid: <1585324297.97.0.65509955463.issue40089@roundup.psfhosted.org> |
| 2020年03月27日 15:51:37 | vstinner | link | issue40089 messages |
| 2020年03月27日 15:51:37 | vstinner | create |
|