[Python-Dev] pthreads, fork, import, and execvp

[Thomas Wouters]

On Wed, Sep 9, 2009 at 23:56, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Thomas Wouters wrote:
> >     Your idea of making this an API called a 'fork lock' or something
> >     sounds good (though I think it needs a better name.  PyBeforeFork &
> >     PyAfterFork?).  The subprocess module, for example, disables garbage
> >     collection before forking and restores it afterwards to avoid
> >     http://bugs.python.org/issue1336.  That type of thing could also be
> >     done in such a function.
> >
> >
> > Unfortunately it's rather hard to make those functions work correctly
> > with the current API -- we can't provide functions you can just use as
> > arguments to pthread_atfork because the global interpreter lock is not
> > re-entrant and we have no way of testing whether the current thread
> > holds the GIL.
>
> I thought "make sure I have the GIL, either by already having it or
> waiting for it if I don't yet have it" was the entire point of the
> PyGILState_Ensure() API? [1]
>

Hm, yeah. For some reason I was certain it was inappropriate, back when I
was trying to create a pthread_atfork-friendly set of functions. At the time
I was also hip-deep in the awfulness of Python/thread*.c and its unsafe
punning and unwarranted assumptions, so I may have overreacted. I added this
as a feature-request issue ( http://bugs.python.org/issue6923 ) and will
look at it some more.

In the mean time, I fixed the biggest source of issues by checking in the
change to make at least calls to fork() made by Python be safe, also
backported to 2.6.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090916/6e4fe89f/attachment-0001.htm>