traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Improve description of issues

This commit is contained in:
Antoine Pitrou 2011-01-15 12:10:48 +00:00
parent 8b50b831b4
commit f1dfe735b5
1 changed files with 9 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
Doc/c-api/init.rst
View File

@ -861,13 +861,16 @@ in one sub-interpreter into a namespace of another sub-interpreter; this should
be done with great care to avoid sharing user-defined functions, methods, be done with great care to avoid sharing user-defined functions, methods,
instances or classes between sub-interpreters, since import operations executed instances or classes between sub-interpreters, since import operations executed
by such objects may affect the wrong (sub-)interpreter's dictionary of loaded by such objects may affect the wrong (sub-)interpreter's dictionary of loaded
modules. (XXX This is a hard-to-fix bug that will be addressed in a future modules.
release.)
Also note that the use of this functionality is incompatible with extension Also note that combining this functionality with :c:func:`PyGILState_\*` APIs
modules such as PyObjC and ctypes that use the :c:func:`PyGILState_\*` APIs (and is delicate, become these APIs assume a bijection between Python thread states
this is inherent in the way the :c:func:`PyGILState_\*` functions work). Simple and OS-level threads, an assumption broken by the presence of sub-interpreters.
things may work, but confusing behavior will always be near. It is highly recommended that you don't switch sub-interpreters between a pair
of matching :c:func:`PyGILState_Ensure` and :c:func:`PyGILState_Release` calls.
Furthermore, extensions (such as :mod:`ctypes`) using these APIs to allow calling
of Python code from non-Python created threads will probably be broken when using
sub-interpreters.
Asynchronous Notifications Asynchronous Notifications