[Mono-dev] Status of COM interop
Ivo Smits
Ivo at UFO-Net.nl
Tue May 3 10:55:02 EDT 2011
Jonathan (and others),
I don't think this issue is playing up yet at run time. None of the
complex/bigger COM objects are released yet, until the application
finishes. At that point I sometimes receive a SIGSEGV, which may be
caused by the releasing of the COM objects. It's no big deal yet. As a
workaround, I suppose I might call Marshal.AddRef when creating the
objects, and when the objects are no longer needed, force a few garbage
collections and then call Marshal.Release from the main thread? This way
the actual freeing of the object should happen with the Marshal.Release
call, and not from the garbage collection...?
I have explained another, more important problem in another mail,
subject "Double/redundant release of COM object while marshaling from
IUnknown (with patch)". Assuming you are involved in the mono project,
did you get a look at this one?
And another thing: In their XPCOM function calls, VirtualBox appears to
use two arguments for passing arrays, an UInt32 for the length and a
pointer to the actual array. What's the best way to deal with this in
the interop code? Is there a way to marshal a managed array directly? I
would like to use the same function prototype on the managed side for
both COM and XPCOM.
This is what a VirtualBox function might look like on Windows and Linux
respectively,
COM function: void doSomething(SAFEARRAY arr);
XPCOM function: void doSomething(int arrSize, Int32* arr);
(desired) interop interface function: void doSomething(Int32[] arr);
--
Ivo
Op 27-4-2011 2:47, Jonathan Chambers schreef:
> ...
>
> Ivo, Joe is right to mention this. I've made all my COM objects free
> threaded to avoid this issue. If your COM objects rely on STA
> behavior, you're going to run into troubles.
>
> Thanks,
> Jonathan
More information about the Mono-devel-list
mailing list