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

[David Cole]

It's always best to prevent crashing in the first place... right? You 
could use a CMake construct like this:
  GET_FILENAME_COMPONENT(LIBNAME ${PYTHON_LIBRARY} NAME_WE)
  STRING(REGEX REPLACE "python" "" LIBVER "${LIBNAME}")
  IF(LIBVER LESS 23)
    MESSAGE(SEND_ERROR "VTK_WRAP_PYTHON requires a minimum of Python 
version 2.3.\nUpgrade python or set VTK_WRAP_PYTHON to OFF to avoid this 
error.")
  ENDIF(LIBVER LESS 23)

...if the following hold true:
VTK_WRAP_PYTHON is ON
PYTHON_LIBRARY is found/set
python libs are always named pythonNN where NN can be legally compared 
to a value like 23... (Assuming future Python 3.0 will be named 
python30.lib/a/so/dll...)


David


Charl P. Botha wrote:

>On 7/4/05, Sander Niemeijer <niemeijer at science-and-technology.nl> wrote:
>  
>
>>>    SN> More info about the PyGILState functions can also be found in
>>>    SN> the PEP <http://python.fyxm.net/peps/pep-0311.html>
>>>      
>>>
>
>  
>
>>I am not sure what you mean. If you mean implementation of the PEP in
>>Python, then this has been done AFAICS (the two new API functions
>>mentioned are implemented now and seem to match the patch that is
>>linked to from the PEP page <http://www.python.org/sf/684256>).
>>    
>>
>
>  
>
>>In that case, the attached patch can be used as a starting point for a
>>final patch. Mind that the API's I am using are not available in Python
>>versions prior to version 2.3, so the calls should probably be
>>encapsulated with something like:
>>
>>---
>>#if (PY_MAJOR_VERSION > 2) || ((PY_MAJOR_VERSION == 2) &&
>>(PY_MINOR_VERSION >= 3))
>>...
>>#endif
>>---
>>
>>I don't know if a proper fix for the thread state initialization and
>>locking exists for Python versions prior to 2.3, so it might be useful
>>to instruct users to build Python/VTK/wxPython without threads if they
>>want the callbacks in elder Python versions to work properly.
>>    
>>
>
>I've finally had some time to go look at the documentation, and this
>would seem to be a good solution to the previous problem as well: i.e.
>explicitly releasing the GIL before every long-running call.  With
>Sander's patch applied, it looks like any VTK thread would be able to
>call back into the main thread without any nasty effects.  Nice.
>
>I'll merge my patch (or what's left of it - mostly just explicitly
>releasing the GIL before long-running VTK methods) with Sander's work
>and then try to break the resulting build.
>
>Any more thoughts on what to do with users of Python < 2.3, besides
>just warning somewhere in the documentation?  Even WITH the GIL lock
>in place, things will crash...
>
>Thanks,
>Charl
>
>  
>