[issue6721] Locks in python standard library should be sanitized on fork

Antoine Pitrou report at bugs.python.org
Wed May 4 19:53:48 CEST 2011


Antoine Pitrou <pitrou at free.fr> added the comment:

> - what's current_thread_id ? If it's thread_get_ident (pthread_self),
> since TID is not guaranteed to be inherited across fork, this won't
> work

Ouch, then the approach I'm proposing is probably doomed.

> And it's true with every lock in the library code: they're only held
> in short critical sections (typically acquired when entering a
> function and released when leaving), and since it's not the threads
> inside those libraries that fork, all those locks can simply be
> reinitialized on fork, without having the reacquire them.

Well, this means indeed that *some* locks can be handled, but not all of
them and not automatically, right?
Also, how would you propose they be dealt with in practice? How do they
get registered, and how does the reinitialization happen?

(do note that library code can call arbitrary third-party code, by the
way: for example through encodings in the text I/O layer)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________


More information about the Python-bugs-list mailing list