[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