Antoine Pitrou <pit...@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 <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