From: Ezio Melotti Date: Wed, 20 Apr 2011 18:32:40 +0000 (+0300) Subject: Merge with 3.1. X-Git-Tag: v3.2.1b1~98 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=861d27f4cff8f2a82ebbb20090b49e754f1135c1;p=thirdparty%2FPython%2Fcpython.git Merge with 3.1. --- 861d27f4cff8f2a82ebbb20090b49e754f1135c1 diff --cc Doc/c-api/init.rst index 535bf12364a0,e78add1041ae..9a78834cdd37 --- a/Doc/c-api/init.rst +++ b/Doc/c-api/init.rst @@@ -489,8 -472,8 +489,8 @@@ the fork, and releasing them afterwards :ref:`lock-objects` in the child. When extending or embedding Python, there is no way to inform Python of additional (non-Python) locks that need to be acquired before or reset after a fork. OS facilities such as - :c:func:`posix_atfork` would need to be used to accomplish the same thing. -:cfunc:`pthread_atfork` would need to be used to accomplish the same thing. -Additionally, when extending or embedding Python, calling :cfunc:`fork` ++:c:func:`pthread_atfork` would need to be used to accomplish the same thing. +Additionally, when extending or embedding Python, calling :c:func:`fork` directly rather than through :func:`os.fork` (and returning to or calling into Python) may result in a deadlock by one of Python's internal locks being held by a thread that is defunct after the fork.