http://codereview.appspot.com/96125/diff/2008/3003 File Doc/c-api/init.rst (right): http://codereview.appspot.com/96125/diff/2008/3003#newcode534 Line 534: of Python's internal locks behind held by a ...
15 years, 1 month ago
(2009-09-09 18:24:56 UTC)
#2
http://codereview.appspot.com/96125/diff/2008/3003
File Doc/c-api/init.rst (right):
http://codereview.appspot.com/96125/diff/2008/3003#newcode534
Line 534: of Python's internal locks behind held by a thread that is defunct
after the
calling fork() from C code isn't a problem by itself.
It is only a problem if the child process ever attempts to return up its stack
back to the Python interpreter. If it stays in C code doing its own stuff it is
perfectly safe. (for example: os.system)
http://codereview.appspot.com/96125/diff/2008/3003 File Doc/c-api/init.rst (right): http://codereview.appspot.com/96125/diff/2008/3003#newcode534 Line 534: of Python's internal locks behind held by a ...
15 years, 1 month ago
(2009-09-09 18:37:28 UTC)
#3
http://codereview.appspot.com/96125/diff/2008/3003
File Doc/c-api/init.rst (right):
http://codereview.appspot.com/96125/diff/2008/3003#newcode534
Line 534: of Python's internal locks behind held by a thread that is defunct
after the
On 2009/09/09 18:24:56, gregory.p.smith wrote:
> calling fork() from C code isn't a problem by itself.
>
> It is only a problem if the child process ever attempts to return up its stack
> back to the Python interpreter. If it stays in C code doing its own stuff it
is
> perfectly safe. (for example: os.system)
That's why it says 'may' :-) But point taken, clarification added.
Issue 96125: Fix import_lock+fork() deadlock.
(Closed)
Created 15 years, 2 months ago by Thomas Wouters (gmail)
Modified 14 years, 7 months ago
Reviewers: gregory.p.smith
Base URL: http://svn.python.org/view/*checkout*/python/branches/release26-maint/
Comments: 2