[Mono-bugs] [Bug 672879] ReleaseInterfaces is called by GC thread.

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Fri Sep 2 11:25:30 EDT 2011



--- Comment #3 from Jonathan Chambers <joncham at gmail.com> 2011-09-02 15:25:29 UTC ---
Miguel and Tom,

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 wrapper object.

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):

Proposed Solution:

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
return value.

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);


Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.

More information about the mono-bugs mailing list