[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