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 ---------------------------------------------------------------
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4