[vtkusers] VTK/Java crashes -- WeakGlobalRef or garbage collection problem...solution?

Luke Dodd luke.dodd at gmail.com
Thu Dec 17 21:13:48 EST 2009


It would be good to hear more about the issues you are having, because
it sounds like they could well impact me. (I'm bulding a fairly heavy
swing app)

If indeed any multithreaded access to vtk code, be it mutex locked or
not, turns out to be a problem there are certainly ways round it.

On the simplest level we could keep the code as it is with my added
lock and have the finalizer warn you if it objects it's called on are
not yet deleted by the user. Then perhaps we could add the
vtkGCContext idea you had. Or... we could periodically sweep through
the vtkWeakGlobalRef map and look for entries that have become null
(i.e. garbage collected) and then call delete on them, this could be
done from whatever thread we wanted and have the advantage of not
forcing the user to manage memory (then we could eliminate the global
lock too, although we would still have to be careful). I could look
into these, but right now I have not actually found it to be an issue
so it would be great if you could isolate an example case (I know this
can be very fiddly to do with this sort of code.)

It's no problem working on this - if I manage to nip any threading
problems in the bud before they rear there heads then I'll be happy!

Luke.

2009/12/18 Nathan P Sharp <vtkusers at nps.parcellsharp.net>:
> Luke Dodd escribió:
>> As far as threading problems are concerned I would have thought a
>> global lock would fix things. It does not really matter what thread
>> any code gets called from as long as there is not more than one thread
>> messing around with non thread safe code.
> This is entirely true for code you write.  However, when you start
> dealing with hardware acceleration and heavy packages like Swing, OpenGL
> and MFC it'll get you in trouble.  Those packages all have very specific
> rules about what you are and are not allowed to do and often use thread
> local storage.  In particular OpenGL is tricky because most of it is
> implemented in drivers by the hardware vendors.  So what works on my box
> might crash rapidly on someone else's hardware, even for the same OS.
>
> http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html
>
> I'm frantically trying to get everything I need done before I go on
> vacation next week.  It might take me a while but I'll get back to you
> on the sample code for the memory leak.  I agree that it sounds like an
> unrelated problem.  Again, thanks for working with me.  I look forward
> to trying out the sync code.
>
> Nathan
>
>



More information about the vtkusers mailing list