On Wed, Sep 9, 2009 at 23:56, Nick Coghlan <ncogh...@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 <tho...@python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
