[Mono-dev] COM, Threads and Mono

[Jonathan Chambers]

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 Fri, Sep 2, 2011 at 1:59 PM, Alan <alan.mcgovern at gmail.com> 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?
>
> Alan
>
>
> On 2 September 2011 18:30, Robert Jordan <robertj at gmx.net> wrote:
>
>> 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 simple as this:
>>
>> ~__ComObject ()
>> {
>>        SynchronizationContext.Current.Post(delegate {
>>                 ReleaseInterfaces ();
>>        });
>> }
>>
>> Consumers publish their own SynchronizationContext with
>> SynchronizationContext.SetSynchronizationContext(
>>        new MySuperCoolSyncContext());
>>
>> Robert
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20110902/a74a6607/attachment.html