Home Original page

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

Nick Coghlan ncoghlan at gmail.com
Wed Sep 9 23:56:44 CEST 2009 
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]

Cheers,
Nick.

[1]
http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock





-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
More information about the Python-Dev mailing list