On Mon, Feb 1, 2010 at 5:20 PM, "Martin v. Löwis" <mar...@v.loewis.de> wrote: > Instead, we should aim to make Python fork-safe. If the primary concern > is that locks get inherited, we should change the Python locks so that > they get auto-released on fork (unless otherwise specified on lock > creation). This may sound like an uphill battle, but if there was a > smart and easy solution to the problem, POSIX would be providing it.
The "right" (as if you can actually use fork and threads at the same time correctly) way to do this is to acquire all locks before the fork, and release them after the fork. The reason is that if you don't, whatever data the locks guarded will be in an undefined state, because the thread that used to own the lock was in the middle of modifying it. POSIX does provide pthread_atfork, but it's not quite enough. It's basically good enough for things like libc's malloc or other global locks held for a short duration buried in libraries. No one will ever try to fork while doing an allocation, for example. The problem is that if you have a complicated set of locks that must be acquired in a certain order, you can express that to pthread_atfork by giving it the callbacks in the right order, but it's hard. However, I think for Python, it would be good enough to have an at_fork registration mechanism so people can acquire and release locks at fork. If we assume that most library locks are like malloc, and won't actually be held while forking, it's good enough. Reid _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
