Could I get a review of the updated patch at:
https://bugzilla.novell.com/show_bug.cgi?id=672879
as I would love to get this into mono if its ok.
--
View this message in context:
http://mono.1490590.n4.nabble.com/COM-Threads-and-Mono-tp3786286p3809758.html
Sent from the Mono - Dev mailing list
Tom,
The patch looks ok to me.
Thanks,
Jonathan
On Tue, Sep 13, 2011 at 7:17 AM, tom_hindle tom_hin...@sil.org wrote:
Could I get a review of the updated patch at:
https://bugzilla.novell.com/show_bug.cgi?id=672879
as I would love to get this into mono if its ok.
--
View this message
Robert Jordan wrote:
How about relying on System.Threading.SynchronizationContext.Current?
This could work w/out exposing any internal calls/env vars.
This is actually a pretty good idea, but you'd need to capture the
SynchronizationContext in the __ComObject constructor, not use the one of
Hello,
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.
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
Hi Jonathan,
How about relying on System.Threading.SynchronizationContext.Current?
This could work w/out exposing any internal calls/env vars.
This way we offload the burden of implementing a suitable
SynchronizationContext on the COM consumer. Done ;)
The necessary runtime changes are as
The System.Windows.Forms sync context runs stuff on the winforms main loop,
so wouldn't it be prone to exactly the message pumping related deadlocks
that were already described?
Alan
On 2 September 2011 18:30, Robert Jordan robe...@gmx.net wrote:
Hi Jonathan,
How about relying on
Alan,
If I understand you correctly, yes it would be prone to same issues. The
bigger problem with COM is that it is frequently used in non-UI applications
without a main loop. As there is no main event loop processing events, the
user needs to make sure they manually process them.
- Jonathan
On 02.09.2011 19:59, Alan wrote:
The System.Windows.Forms sync context runs stuff on the winforms main loop,
so wouldn't it be prone to exactly the message pumping related deadlocks
that were already described?
Well, not more deadlock prone than providing a callback and
hoping that the
