Embedding Python in a C extension

kai028 kai_28_2000 at yahoo.com
Thu Jun 3 13:26:40 EDT 2010


Thanks for the reply. I'm checking this out today.

On Wed, 2 Jun 2010 22:30:37 -0700 (PDT), Carl Banks
<pavlovevidence at gmail.com> wrote:

>On Jun 2, 1:46 pm, Paul Grunau wrote:
>> I have a problem with embedding Python into a C extension in Windows
>> Vista. I have implemented a timer routine in C as an extension, which
>> I can import into Python 2.6.5 and run. Each timer interval, the
>> extension calls a C CALLBACK function. I want to be able to have this
>> CALLBACK function call a Python function, so that I can write the
>> timer handler in Python.
>>
>> I can write Python functions and call them from a C extension function
>> with no trouble in all cases EXCEPT when the function that calls the
>> Python code is the timer's CALLBACK function. That is, if I call
>> PyRun_SimpleString or PyRun_SimpleFile, or PyImport_ImportModule, or
>> basically any Python-y function in the CALLBACK function, Python
>> crashes and I get a window saying "Python has stopped working. Windows
>> is searching for a solution to the problem."
>>
>> The Python code runs fine if I call it from a function in the
>> extension that is not the CALLBACK function. And regular C code runs
>> in the CALLBACK function properly. It only crashes if I try to run the
>> Python code from the timer CALLBACK function (or any C function I call
>> from the CALLBACK function).
>>
>> Does anybody know how to fix this? Is there a workaround of some sort?
>
>See PEP 311.  When an external/uncertain thread calls into Python, it
>has to be sure a Python thread state exists for that thread, and that
>the thread holds the global interpreter lock.  This is done by
>surrounding all Python code with the following calls:
>
>PyGILState_STATE state = PyGILState_Ensure();
>
>and
>
>PyGILState_Release(state);
>
>Normally, code in extension modules can rely on the current thread
>having the global lock at all entry points, so it doesn't have worry
>about the thread state.  But a callback from a timer can't assume
>that.
>
>
>Carl Banks



More information about the Python-list mailing list