[Pyrex] GIL question

Phillip J. Eby pje at telecommunity.com
Wed Oct 6 23:28:37 CEST 2004


At 03:00 PM 10/6/04 -0400, Bob Ippolito wrote:

>On Oct 6, 2004, at 2:51 PM, Phillip J. Eby wrote:
>
>>At 11:36 AM 10/6/04 -0700, Cory Dodt wrote:
>>
>>>Does Pyrex provide any way to release the GIL?
>
><PyEval_SaveThread() / PyEval_RestoreThread() example>
>
>>I pretty much translated the above straight from "8.1 Thread State and 
>>the Global Interpreter Lock" in the Python/C API manual.  Note, however, 
>>that you should only invoke the functions if thread support is 
>>present.  (#ifdef WITH_THREAD), so you may need to actually use a 
>>different header file, with something like this in it:
>
>Thread support is always present in this case so that is not an issue.
>However, the problem is the opposite of what was previously described.
>cfreactor has its callbacks called without the GIL so they need to acquire 
>the GIL, run Python code, and release the GIL... without generating any 
>exception blocks, reference counting, etc. after the PyGILState_Release().

Ah.  For that, you need a 'cdef' function without any 'object' parameters 
or variables.  e.g.:

cdef void this_is_a_callback():
     PyGILState_Ensure()
     # do stuff w/Python...
     PyGILState_Release()

Avoid using any "object" or non-cdef variables anywhere in the body of your 
routine, in order to avoid any refcount cleanup code being 
generated.  Temporary casts to <object> are probably okay.

If that still doesn't work, you'll have to write your callback as a C 
routine with the Ensure/Release wrapping a call to the cdef function.

(It's relatively easy to mix C with Pyrex; just add the needed '.c' file's 
name to the list of source files in the Extension sources of your setup.py.)





More information about the Pyrex mailing list