[vtkusers] VTK and Java Wrappers

[Denis Barbier]

On 2010/3/9 Jeff Baumes wrote:
>
> I agree that we should add a resolution for this issue in the upcoming VTK release. The problem is that VTKDelete() happens in finalize(), which is run on a separate thread and can cause concurrency issues. There are currently 3 proposed solutions (that I know of):
> 1. Use a shared mutex lock around every VTK call (including Delete()).
> 2. Have finalize() dispatch VTKDelete() calls to the thread that VTK objects are allocated/used (normally the event thread).
> 3. Have no finalizers, but periodically traverse vtkGlobalJavaHash and delete objects whose weak reference is null.
> Denis Barbier has made patches on gitorious for solutions 1 and 2, originally made by Nathan Sharp and Luke Dodd:
> On Unix:
>  $ git clone git://gitorious.org/~dbarbier/kitware/dbarbier-vtk.git vtk-test
>  $ cd vtk-test
>  $ git checkout -b java/globalLock origin/java/globalLock
>  [build...install...test]
>  $ git checkout -b java/proxyFinalize origin/java/proxyFinalize
>  [build...install...test]
>
> I think I prefer the proxyFinalize solution (solution 2 above), but others who have more experience with VTK+Java can give their opinions. I'll plan to check in a fix in the coming days.

The situation is a little bit more complex, there are in fact 3
distinct problems:
 1. vtkGlobalJavaHash may be corrupted, see
http://www.vtk.org/Bug/view.php?id=8942
 2. Some objects must be destroyed in the same thread as they have been created
 3. Objects which modify drawing surface must be destroyed within
vtkPanel.Lock()/vtkPanel.UnLock()

We are here discussing the 2nd point only.  It would be really nice if
the first point could be fixed, Jeff, it does require a deep knowledge
of VTK garbage collector to make sure that the provided patch works as
expected.  We have tested it thoroughly for a long time and are pretty
sure that it is right, but maybe we missed corner cases.

About the 3rd point, I missed that during the previous discussion, but
some objects have to be deleted within calls to
vtkPanel.Lock()/vtkPanel.UnLock(), see comments in
Common/vtkJavaAwt.h.  We did not fully investigate which objects are
concerned, we observed that deleting a vtkMapper without locking
crashes quite reliably.  For this reason, it is very important to be
able to free C++ objects without a proxy, and am afraid that current
java/proxyFinalize branch does not allow it.  I will work on it to fix
that.

Denis