This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gfe
Recipients
Date 2006-05-30.12:58:00
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
[Split off from closed 1453341, which desired a Python-
level API. This request is for a C API, to be used in 
C extensions that call back into Python.]

I think it would be very useful to have an API that 
would tell Python not to release the GIL during call 
backs to Python code, until it is told again (back in 
C code) that it is ok to do so.

I'd like to quote Tim Peters, who explains it better 
than me (private conversation, June 2005):
----------
It would be more feasible to patch Python, introducing 
a way to tell the interpreter not to allow other 
_Python_ threads to run. It has such a mechanism 
already (the GIL -- the global interpreter lock), but 
as soon as C code calls back into Python, the 
interpreter may release the GIL and give ownership of 
it to a different thread. I think it would be pretty 
easy to introduce a Python C API to say "don't allow
other Python threads to run until I tell you 
otherwise". 
----------

The Use Case arose with a multi-threading problem in 
ZODB's Connection, where the C code must ensure that 
no other thread runs Python code accessing an object 
BUT the own thread needs to call back into Python. 

Any other mechanism that came to my mind would either 
require to halt *all* others threads, or run into race 
conditions. 

Best regards, Martin Gfeller
History
Date User Action Args
2008-01-20 09:59:47adminlinkissue1497532 messages
2008-01-20 09:59:47admincreate