Antoine Pitrou <pit...@free.fr> added the comment: > Also, this would imply keeping track of the thread currently owning > the lock,
Yes, we would need to keep track of the thread id and process id inside the lock. We also need a global variable of the main thread id after fork, and a per-lock "taken" flag. Synopsis: def _reinit_if_needed(self): # Call this before each acquire() or release() if self.pid != getpid(): sem_init(self.sem, 0, 1) if self.taken: if self.tid == main_thread_id_after_fork: # Lock was taken in forked thread, re-take it sem_wait(self.sem) else: # It's now released self.taken = False self.pid = getpid() self.tid = current_thread_id() > and doesn't match the typical pthread_atfork idiom (acquire locks just > before fork, release just after in parent and child, or just reinit > them in the child process) Well, I fail to understand how that idiom can help us. We're not a self-contained application, we're a whole programming language. Calling fork() only when no lock is held is unworkable (for example, we use locks around buffered I/O objects). ---------- _______________________________________ 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