Charles-François Natali added the comment: > Christian Heimes added the comment: > > I think it's more likely that my patch is triggering an existing bug. The > locking code for the SSL module and OpenSSL doesn't release locks on fork. I > have attached an experimental patch that unlocks all locks in the client.
The problem is that this patch can make it even more deadlock-prone: pthread_mutex_unlock() isn't async-signal safe (it's not just theory: depending on the implementation, I've seen it deadlock on some platforms, even on Linux IIRC). Also, there's another problem with the approach of "unlocking locks in the child process": locks are usually used to protect critical sections, i.e. sections of code where an invariant must be preserved between entry and exit: by merely unlocking the locks in the child process, we can - maybe, see above - prevent deadlocks, but the data protected by those locks can very-well be left in an inconsistent state. So we might be trading a deadlock for a non-functional ssl library in the child process, which would be - from a security POV - even worse. Really, adding fork-hooks is a bad idea: unfortunately, I don't have anything better to suggest :-(. Except maybe adding an add-hoc hook to posix_fork(), like the ones used to reset the GIL, threading module etc: at least, it will not make the interpreter less safe than now, and won't be able to deadlock processes that are conform and use subprocess to create processes... ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19227> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
