[vtk-developers] Patch to vtkWrapPython.c to make wrapped Python code GIL-friendly

[David Gobbi]

Hi Charl,

It sounds good.  The only question I have is about observers.  What happens
when a python function has been set as an observer for a VTK event?
Have you changed the code for vtkPythonCommand::Execute() to do all
the proper locking and unlocking?  (Note: vtkPythonCommand is in
vtkPythonUtils.cxx).

 - David

Charl P. Botha wrote:

>Dear VTK-developers and Python-heads,
>
>The Python GIL, or global interpreter lock, prevents Python threads
>from running concurrently [1].  It sounds strange, but it's true.
>
>Due to the GIL, when one Python thread is calling a long-running VTK
>method, no other Python threads are allowed to execute.  I've made a
>small patch (attached) to vtkWrapPython.c that alleviates this problem
>in the VTK Python wrappings by giving up the GIL just before the
>actual call to VTK code and taking it back directly after.  I've
>tested this, and now multiple VTK threads, invoked from Python, run
>concurrently.  Python's thread-safety is not affected, as the GIL is
>given up and taken back around a block containing no Python API calls.
>
>I would like to apply this to VTK CVS.  It shouldn't affect any
>existing code, but will improve the current state of affairs with
>regards to multi-threaded VTK Python code.  Comments?
>
>Thanks,
>Charl
>
>[1] http://docs.python.org/api/threads.html
>  
>