[Mono-dev] COM, Threads and Mono
joncham at gmail.com
Fri Sep 2 11:26:02 EDT 2011
Miguel and Tom,
I added this same response to the bug report.
This was an issue I ignored when initially implementing COM interop for
mono. Theoretically, we should be marshaling (in the COM sense) interfaces
between threads to properly support COM apartments. We don't at this point,
but as long as the user code is not accessing the COM object from multiple
threads it should not be an issue. The only place we force the access of a
COM object from a different thread is in the case of finalization of the
The problem with COM marshalling between threads is that you can easily
cause deadlock. Cross apartment (thread) COM calls are handled via Windows
messages. If you perform a wait on a thread (Sleep, WaitForSingleObject,
etc) that does not pump messages, or have a processing loop that does not
pump messages you will run into hangs or deadlock.
Problem in short:
1. We are not currently marshaling COM interfaces
2. Marshaling could be done, but could introduce deadlocks without message
3. The run time would need to use message pumping waits where possible
4. What to do on non-Windows platforms? There is no Win32 message pump
5. Even if we do all this, you can still get deadlocks. See long post on
msdn from cbrumme. tl;dr it's a mess and took hacks in the CLR (from 2004):
I think we should just solve the finalizer issue, rather than the general
marshaling issue. Of course we cannot add a new API to class libs, but how
about either a environment variable
Assuming the function specified is signature taking a single IntPtr and no
Or, we could export a function in the runtime that could be called via an
icall when running on mono.
void mono_set_com_finalizer(Action<IntPtr> func);
On Fri, Sep 2, 2011 at 11:05 AM, Miguel de Icaza <miguel at xamarin.com> wrote:
> Tom filed recently a bug against Mono that boils down to Mono calling
> the finalizer for COM objects in the finalizer thread, which is something
> that most COM applications are not expecting.
> His solution is to extend the .NET API to do this, which is not going
> to work for Mono. What is probably happening is that we have not correctly
> implemented the semantics for destruction of COM objects. That said, I do
> not know enough about COM to know how this is handled on Windows.
> If you know some COM, I would love if you could take a look at this:
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list