[vtk-developers] Patch to vtkWrapPython.c to make wrapped Python code GIL-friendly
Sander Niemeijer
niemeijer at science-and-technology.nl
Fri Jul 1 08:55:07 EDT 2005
Hi,
I just found the discussion between Charl and Prabhu about VTK and
Python thread safety through Google (I wasn't even aware that VTK had a
special developers mailinglist that I could subscribe to). A very
interesting read.
The point is, I have already been bitten by the current behaviour of
vtkPythonCommand::Execute.
When in our wxPython/VTK application a vtkPytonCommand::Execute is
called to run a Python method (that was registered as observer on a VTK
object) we receive a SEGFAULT:
PyFrame_New (tstate=0x0, code=0x43997a20, globals=0x4187c3e4,
locals=0x0)
at Objects/frameobject.c:540
540 PyFrameObject *back = tstate->frame;
The tstate (current Python thread state) is NULL, which should never
happen.
I was first able to 'fix' this by just building everything (i.e.
Python, VTK, wxPython) without thread support, but I recently
discovered the PyGILState API and was able to fix our crash by adding
PyGILState_Ensure() and PyGILState_Release() calls to the
vtkPythonCommand:Execute function.
My question is: is there a reason why (at least for Python 2.3 and up)
these functions are not used to properly grab the GIL?
More info about the PyGILState functions can also be found in the PEP
<http://python.fyxm.net/peps/pep-0311.html>
Unfortunately I am not that familiar with Python threading issues, but
shouldn't the following functions in vtkPythonUtil.cxx also be equipped
with GIL grabbers?
- vtkPythonVoidFunc
- vtkPythonVoidFuncArgDelete
- vtkPythonDeleteCommand::Execute
Best regards,
Sander Niemeijer
More information about the vtk-developers
mailing list