Charles-François Natali <neolo...@free.fr> added the comment: > However, extending RLock to provide ForkClearedRLock (this would be used by > logging, i.e.) is quite straighforward. > > The extended class would simply need to record the process ID, in which the > lock was created, and the process ID, which is trying to acquire it. Done!
There are at least two problems with this approach. - with LinuxThreads, threads have different PIDs, so this would break. LinuxThreads have now been replaced with NPTL, so this may not be a showstopper, though - however, the other problem is more serious: it has the exact same problem as the lock reinitialization upon fork(): locks are used to protect critical sections, to make sure that threads see a consistent state: if you simply proceed and reset/acquire the lock when the process is not the last one that owned it, the invariants protected by the lock will be broken. The proper solution is to setup handlers to be called upon fork, that not only reset locks, but also internal state of objects they protect. However, this is a dull and boring task, and would require patching dozens of different places. It's been on my todo list for some time... Another "solution" would be to remove the only place in the standard library where a bare fork() is used, in multiprocessing (issue #8713). Then, it's the user's problem if he calls fork() :-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6721> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
