[vtkusers] Garbage collection and .NET problem

[Laurent Peters]

Hi Serge,

I think I encountered the same problem with Java a few days ago. I posted a
question on this forum but received no answer.
What I did, is that I added an object in a static java field of vtkObject
and I 'synchronize' the 'Delete' and all my calls to VTK API on that object,
in order to avoid to concurrent calls to VTK API. However, this solution is
not very nice and I am not sure it will solve the problem.

I would be really very interested in any other solution to this problem.

Laurent

On Thu, Oct 23, 2008 at 5:29 PM, Serge Lalonde <serge at infolytica.com> wrote:

>  Hi David,
>
> I tried calling Dispose on the objects, but that doesn't work for many
> reasons.
>
>    1. It's ugly.
>    2. It's very difficult to maintain.
>    3. Often, wrapper objects are not stored in a variable if the call to
>    Get*() is daisy-chained, so it's impossible to call Dispose() on it.
>       ex: actor.GetMapper().SetLookupTable(lut).
>    Here the mapper wrapper holds a reference to the VTK mapper until the
>    GC decides to cleanup.
>
> So in practice, explicitly calling Dispose() is not really possible.
>
> It seems to me to be a fairly simple problem to solve that would benefit
> all VTK wrappers and also C++. I've come up with a scheme to fix it, but I
> didn't want to implement it if there was an official VTK workaround. If
> nobody else replies , I'll implement it and post my code for this in case
> others they find it useful.
>
> BTW, do you happen to know what
> vtkGarbageCollector::DeferredCollectionPush() is supposed to do? It looks to
> me like it could be part of the solution, but as it is, it doesn't seem to
> fix anything (I used it and traced the code).
>
> Thanks.
>
> David Cole wrote:
>
> To avoid the problem, try calling Dispose on any .NET objects associated
> with a RenderWindow from the main GUI thread *before* those .NET objects are
> out of scope and eligible for garbage collection.
>
> You can also get that error even solely on the main GUI thread if objects
> associated with the RenderWindow are not Disposed *before* the render window
> itself goes out of scope.
>
>
> On Wed, Oct 22, 2008 at 4:44 PM, Serge Lalonde <serge at infolytica.com>wrote:
>
>>
>> I have run into a problem caused by a conflict between the .NET garbage
>> collection and the VTK garbage collection. However, I believe that this is a
>> general problem that could occur when using Java or even C++ if a vtk object
>> were deleted in a different thread.
>>
>> Because certain objects require that they be freed in the main thread
>> (actually the rendering thread) because they need to free OpenGL resources
>> in their ReleaseGraphicResources() method (ex: vtkOpenGLTexture), they
>> cannot be freed in the .NET garbage collection thread. Doing so causes an
>> error in vtkWin32OpenGLRenderWindow::MakeCurrent() at line 218 when calling
>> wglMakeCurrent() because the rendering context is not valid for this thread.
>>
>> I did some digging and found vtkGarbageCollector::DeferredCollectionPush()
>> that looked perfect. However, it unfortunately didn't work. There doesn't
>> seem to be much documentation on this or in the mailing list.
>>
>> 1. Does anyone know what DeferredCollectionPush() does and what it is
>> meant to actually fix?
>> 2. Has anyone run into this problem and if so, how did you fix it?
>>
>   --
> www.infolytica.com
> 300 Leo Pariseau, Suite 2222, Montreal, QC, Canada, H2X 4B3
> (514) 849-8752 x236, Fax: (514) 849-4239
>
> _______________________________________________
> This is the private VTK discussion list.
> Please keep messages on-topic. Check the FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20081024/0455d8d7/attachment.htm>