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 -- http://mail.python.org/mailman/listinfo/python-list
