Miguel and Tom,<div><br></div><div>I added this same response to the bug report.<br><div><br></div><div>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&#39;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 wrapper object.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Problem in short:</div><div>1. We are not currently marshaling COM interfaces</div><div>2. Marshaling could be done, but could introduce deadlocks without message pumping</div><div>3. The run time would need to use message pumping waits where possible </div>
<div>4. What to do on non-Windows platforms? There is no Win32 message pump</div><div>5. Even if we do all this, you can still get deadlocks. See long post on msdn from cbrumme. tl;dr it&#39;s a mess and took hacks in the CLR (from 2004): <a href="http://blogs.msdn.com/b/cbrumme/archive/2004/02/02/66219.aspx">http://blogs.msdn.com/b/cbrumme/archive/2004/02/02/66219.aspx</a></div>
<div><br></div><div>Proposed Solution:</div><div><br></div><div>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</div>
<div><br></div><div>MONO_COM_FINALIZER_FUNC=&lt;TypeName.FuncName&gt;</div><div><br></div><div>Assuming the function specified is signature taking a single IntPtr and no return value.</div><div><br></div><div>Or, we could export a function in the runtime that could be called via an icall when running on mono.</div>
<div><br></div><div>[DllImport(&quot;__Internal&quot;)]</div><div>void mono_set_com_finalizer(Action&lt;IntPtr&gt; func);</div><div><br></div><div>Thoughts?</div><div><br></div><div>Thanks,</div><div>Jonathan</div><div><br>
</div><div> </div><div><br><div class="gmail_quote">On Fri, Sep 2, 2011 at 11:05 AM, Miguel de Icaza <span dir="ltr">&lt;<a href="mailto:miguel@xamarin.com">miguel@xamarin.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello,<div><br></div><div>    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.</div>

<div><br></div><div>     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.</div>

<div><br></div><div>     If you know some COM, I would love if you could take a look at this:</div><div><br></div><div><a href="https://bugzilla.novell.com/show_bug.cgi?id=672879" target="_blank">https://bugzilla.novell.com/show_bug.cgi?id=672879</a></div>

<div><br></div><font color="#888888"><div>Miguel</div>
</font><br>_______________________________________________<br>
Mono-devel-list mailing list<br>
<a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
<br></blockquote></div><br></div></div>