[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