[issue13778] Python should invalidate all non-owned 'thread.lock' objects when forking

Changes by Charles-François Natali : -- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Locks in python standard library should be sanitized on fork ___ Python tracker

[issue13778] Python should invalidate all non-owned 'thread.lock' objects when forking

lesha added the comment: Actually, I think it does not matter which thread owns the lock, it is still invalid to try to acquire a lock that was grabbed by the fork() parent. Why? Because the fork() parent cannot free the child's copy of the lock anyway, and it's guaranteed to be dead also. -

[issue13778] Python should invalidate all non-owned 'thread.lock' objects when forking

New submission from lesha : Here is a great description of the issue: http://docs.oracle.com/cd/E19683-01/806-6867/gen-1/index.html This enhancement proposes a way to make Python more resistant to this kind of deadlock. Consider this program: import threading import subprocess import time