[Mono-dev] Threads and X-Windows?

[Leszek Ciesielski]

The fact that 'it runs on Windows' might not mean it's correct -
MS.Net used to tolerate accessing the UI controls from other threads
than the one running the message loop, when suddenly this changed
(with Vista AFAIK) many applications suddenly broke - because they
weren't written according to the documentation but with 'whatever
works' approach.

On Thu, May 31, 2012 at 3:07 PM, Rob Wilkens <robwilkens at gmail.com> wrote:
>
> Incidentally (and this is not a personal reply, this is gereral to anyone
> interested), relating to the below reply, unlike .NET, in mono more than one
> thread can be processing the message loop, and delivering the same UI
> messages to more than one thread.
>
> That is, more than one thread can run Application.Run() in mono, and that
> call will start a message processing and passing loop in each thread -- on
> mono anyway.  If you do this on Windows, the second call to
> Application.Run() will just return without doing anything if one is already
> running.
>
> I've fixed this locally, but i'm trying to debug some semi-related issues
> with code which was previously using two Application.Run() calls (one per
> thread).  I'm trying to debug this from the mono side rather than the code
> side, because this code actually does run in Windows as it is written.  Not
> ready to talk about those specific fixes yet, because i'll not be convinced
> it's a good idea until I'm convinced it's a good idea (and until it's bug
> free; not there yet).
>
> I spent all day yesterday staring at the laptop, I'm tempted to give myself
> the day off today, but i may change my mind after coffee and breakfast.
>
>
> -Rob
>
> On 05/30/2012 04:02 PM, Patrick Cullen wrote:
>>
>> In .NET  there is only one thread that does UI work, this is how you
>> access it irrespective of what thread makes the call. I use this for
>> event patterns often. The key is "SendOrPostCallback" which determines
>> if you are running on the UI thread.
>>
>> I use this code often and it works under Mono. I think the behavior is
>> very different but the end result is what I am looking for.
>>
>> Patrick
>>
>> protected SynchronizationContext _uiContext;
>> _uiContext = WindowsFormsSynchronizationContext.Current;
>>
>> _uiContext.Send(new SendOrPostCallback(
>>          delegate(object state)
>>          {
>>                // * Interact with controls here
>>          }
>>    ), null);
>>
>>
>> On Wed, May 30, 2012 at 2:56 PM, Rob Wilkens<robwilkens at gmail.com>  wrote:
>>>
>>> I'm troubleshooting a problem in System.Windows.Forms (or an application
>>> which uses it):
>>>
>>> Does anyone know of problems where messages processed from thread a can't
>>> reach a window created in thread b?  That is, if thread a is processing
>>> messages, those messages don't reach the windows created in thread b?  By
>>> messages, i mean things like WM_CLOSE and WM_PAINT (or invalidate? or
>>> whatever the equivalents are)...  (Messages that are processed, in
>>> theory,
>>> by Application.Run() in thread a)...
>>>
>>> I'm trying to figure out if this is an X11 issue or a mono issue..  I'm
>>> thinking depending on how the day goes i may break from troubleshooting
>>> this
>>> soon.
>>>
>>> Before you say this is a bad idea (multiple threads creating windows)
>>> keep
>>> in mind this was code in a problem report and In windows .net messages
>>> processed in thread a reach windows created in thread b without issue.
>>>  At
>>> least as far as i can tell.
>>>
>>> _______________________________________________
>>> 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