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

[Charl P. Botha]

On 6/17/05, David Gobbi <dgobbi at atamai.com> wrote:
> On the other point about observers being called from a different thread
> than the one
> that set the observer, it seems that you need to maintain a data
> structure that keeps
> track of all the python thread structs and you need some way of figuring
> out which
> one to use when an observer is called.  It definitely sounds doable to me.

Is this allowed in C++?  I.e. if I'd create an observer in one thread,
and then add it to a VTK object in another thread, does VTK guarantee
that this will work?

With regards to the data structure that you suggest: the question is
how critical it is to get an up-to-date PyThreadStruct.  If this needs
to be kept completely up to date, then it's not as straight-forward:
by the time the long running C code runs, getting the PyThreadStates
of all its various observers that could be running in different
threads is very difficult.  If the PyThreadState does not have to be
kept completely up to date, then my solution of doing it in the
constructor of the vtkPythonCommand is not such a bad idea: this means
that the vtkPythonCommand will always be executed in the thread that
it was created.  I'm with Prabhu on this one: it does seem that the
ThreadState needs to be up to date.

However, one could also say that by definition, all observer objects
will be executed in the same thread as the object that they are
observing.  I would then somehow store a PyThreadState whenever the
GIL is given up and allow the vtkPythonCommand to get at this stored
value.  IMO, this is the simplest and most predictable solution, and
thus also the one I prefer.

Your thoughts?

Thanks,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/

c.p.botha ||at|| ewi.tudelft.nl - tu delft work-related email
cpbotha ||at|| cpbotha.net - everything else