> 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...