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

Antoine Pitrou report at bugs.python.org
Wed May 4 00:05:37 CEST 2011


Antoine Pitrou <pitrou at 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 <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________


More information about the Python-bugs-list mailing list