[vtkusers] VTK+Java Crash while rendering

[Shyam Prakash]

Jeff,
	Thanks for this. I have implemented your idea and have succeeded
in this to a great extent. I never had a crash in paint method call
since I implemented this. Can you please check in some comments into
vtkPanel.java so that it will help the future users. Below I have pasted
your own ideas. May be you can add them with any modifications you feel
necessary

"in a nutshell, vtk is not threadsafe.  multithreaded languages such as
java expose this weakness and
make it difficult to implement our ideas without also considering the
impact threads will have.  there
are 2 main places which threads are causing problems - the first is on
the drawing surface (the
underlying Canvas object).  Lock/UnLock is used to lock the drawing
surface to make sure that only one
thread accesses the drawing surface at a time.  the other place where
threads must be considered is in
the pipeline itself.  basically you can have one thread modifying the
data in the pipeline, and another
trying to display it.in general, though, I would use a lock which is set
when modifying the data and
released when finished modifying.  then you could overload the Render()
method in vtkPanel.java to
obtain the lock before actually calling rw.Render().  if you cannot
obtain the lock, then you can either
throw out the render, or re-schedule it.in a render-centric world, the
data-changer-guy would have to 
grab the mutex from the renderer-guy before being able to change the 
data.  if the renderer-guy is busy, back off and update the data later.

n a data-changer-centric world, the opposite."

 
>>no, i mean a real mutex, i.e. one from doug lea's concurrent lib, or 
>>even a simple globally-accessible Object lock.  Lock/UnLock do not
know 
>>anything about what you are doing with the data, they just mutex the 
>>drawing surface.  anyway, the basic idea is to check out the mutex
when 
>>rendering, and have that mutex accessible to the class which is
changing 
>>the data.  in a render-centric world, the data-changer-guy would have
to 
>>grab the mutex from the renderer-guy before being able to change the 
>>data.  if the renderer-guy is busy, back off and update the data
later.  
>>in a data-changer-centric world, the opposite.  make sense?  vtk is a 
>>non-thread-safe toolkit.  this is one of those things that cannot be 
>>built into vtkPanel, but must be built into your system.
>>Jeff


Thanks
Shyam