View mode: basic / threaded / horizontal-split · Log in · Help
July 26, 2012
Re: Multi-threaded GUI
On Thu, Jul 26, 2012 at 2:15 PM, Russel Winder <russel@winder.org.uk> wrote:

> On Thu, 2012-07-26 at 13:45 +0400, Gor Gyolchanyan wrote:
>
> > So the good way to do this will be to have a single thread, which pumps
> > messages and distributes the appropriate message handlers to worker
> > threads, right?
> >
> > My goal here is to have 100% working and responsive GUI no matter how bad
> > the application lags. If, for instance, The user would push a button,
> which
> > initiates a very expensive computation, I don't want the GUI to become
> > stuck. If the user doesn't wait and pushes the button again, it should
> > display a message, which says "The operation is already in progress" or
> > something like that.
>
> Your goal is excellent. Throughout the early 2000s my staff had to
> suffer the stupidities of software development environments that failed
> to take this message on.
>
> The "standard model" for doing this is for user event callbacks to
> always act and if they need to do something that takes longer than a
> very few instructions and/or takes more that a fraction of second (NB
> user reaction time is around 0.2s, user boredom time is around 2s) spawn
> a thread to undertake the work. If that then involves interaction, the
> thread puts an event on the event queue and terminates.
>
> Separation of concerns is also important here: no business logic in the
> GUI code, no GUI code in the business logic. MVC (*), Mediator, Façade,
> are your friends.
>
> (*) Microsoft's MVP variant of MVC is probably very appropriate on
> Windows.
> --
> Russel.
>
> =============================================================================
> Dr Russel Winder      t: +44 20 7585 2200   voip:
> sip:russel.winder@ekiga.net
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>

I totally agree with separation of GUI and logic. The problem is, that the
engine should be generic, so there's no way of determining whether the
incoming handler is big enough for a thread or not.

What is Microsoft's MVP variant of MVC?

-- 
Bye,
Gor Gyolchanyan.
July 26, 2012
Re: Multi-threaded GUI
On Thu, 2012-07-26 at 14:33 +0400, Gor Gyolchanyan wrote:
[…]
> I totally agree with separation of GUI and logic. The problem is, that the
> engine should be generic, so there's no way of determining whether the
> incoming handler is big enough for a thread or not.

But the engine should not be making those decisions, they have to be
made by the callback.

> What is Microsoft's MVP variant of MVC?

Google is your friend ;-)

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter
http://www.codeproject.com/Articles/288928/Differences-between-MVC-and-MVP-for-Beginners
http://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference

Sadly there is also a lot of real rubbish on the Web purporting to be
quality information, as is highlighted in one or two of the answers on
StackOverflow :-(

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
July 26, 2012
Re: Multi-threaded GUI
On 2012-07-26 11:45, Gor Gyolchanyan wrote:

> So the good way to do this will be to have a single thread, which pumps
> messages and distributes the appropriate message handlers to worker
> threads, right?

It should be possible to have other threads interacting with the GUI as 
long as they do that by sending messages to the thread responsible to 
for GUI. Here's an example of an SWT snippet that does GUI manipulation 
from a different thread:

http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet130.java

On line 42 a new thread is created. On line 48 the GUI is changed, by 
adding a string to some text widget. But this happens using the 
"display.syncExec" method. This force the code to be executed on the GUI 
thread instead of the current thread.

-- 
/Jacob Carlborg
July 26, 2012
Re: Multi-threaded GUI
On Thursday, 26 July 2012 at 09:46:26 UTC, Gor Gyolchanyan wrote:
> So the good way to do this will be to have a single thread, 
> which pumps
> messages and distributes the appropriate message handlers to 
> worker
> threads, right?
>
> My goal here is to have 100% working and responsive GUI no 
> matter how bad
> the application lags. If, for instance, The user would push a 
> button, which
> initiates a very expensive computation, I don't want the GUI to 
> become
> stuck. If the user doesn't wait and pushes the button again, it 
> should
> display a message, which says "The operation is already in 
> progress" or
> something like that.

Are you sure you can create a complex window fast enough when 
every operation is asynchronous? I usually find applications 
built with complex ui frameworks start slow. Isn't it because it 
takes long to create a window going through all the framework 
infrastructure?

About separation of ui logic and business logic I suggest to look 
at MVVM pattern (or PresentationModel according to Fowler's 
terminology). Well, it doesn't allow ad-hoc code and implies 
extensive design work for every View, but by ensuring that the 
ViewModel contains only plain data, you're guaranteed that 
business logic is separated from ui logic.
July 26, 2012
Re: Multi-threaded GUI
>"Russel Winder"  wrote in message 
>news:mailman.675.1343290603.31962.digitalmars-d@puremagic.com...
> So if Windows is really doing multi-threaded widget management, this
>would be very interesting.  Where is the material that I can look at
>that leads you to say that Windows is a multi-threaded UI.

At the moment I can only post this, as I am at work and don't have much time 
to search for info.

[quote]The system maintains a single system message queue and one 
thread-specific message queue for each GUI thread.[/quote]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644927%28v=vs.85%29.aspx

--
Paulo
July 26, 2012
Re: Multi-threaded GUI
On 26/07/2012 09:16, Russel Winder wrote:
> On Wed, 2012-07-25 at 23:17 +0200, Kagamin wrote:
>> On Wednesday, 25 July 2012 at 18:50:51 UTC, Simon wrote:
>>> You have to be very, very careful with trying to do multi
>>> threading w/ windoze windows. Try doing a google search on it,
>>> and the advice is invariably: don't do multi threaded windows.
>>> Everybody including people famous for their in-depth window
>>> knowledge recommends a single thread UI with non-UI worker
>>> threads.
>>
> So if Windows is really doing multi-threaded widget management, this
> would be very interesting.  Where is the material that I can look at
> that leads you to say that Windows is a multi-threaded UI.

On 'doze every thread can have it's own message pump and therefore it's 
own UI, but if you have an ancestor/descent relation between 2 windows 
they must belong to the same thread.

Otherwise you are pretty much guaranteed a deadlock, unless you only 
ever use MsgWaitForMultipleObjectsEx to synchronise. But that's kinda of 
unachievable unless you have written every single line of code yourself.

So you can have threads with separate UIs as long as you don't make the 
windows of one thread the child of another.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
July 27, 2012
Re: Multi-threaded GUI
Am 26.07.2012 19:15, schrieb Simon:
> On 26/07/2012 09:16, Russel Winder wrote:
>> On Wed, 2012-07-25 at 23:17 +0200, Kagamin wrote:
>>> On Wednesday, 25 July 2012 at 18:50:51 UTC, Simon wrote:
>>>> You have to be very, very careful with trying to do multi
>>>> threading w/ windoze windows. Try doing a google search on it,
>>>> and the advice is invariably: don't do multi threaded windows.
>>>> Everybody including people famous for their in-depth window
>>>> knowledge recommends a single thread UI with non-UI worker
>>>> threads.
>>>
>> So if Windows is really doing multi-threaded widget management, this
>> would be very interesting.  Where is the material that I can look at
>> that leads you to say that Windows is a multi-threaded UI.
>
> On 'doze every thread can have it's own message pump and therefore it's
> own UI, but if you have an ancestor/descent relation between 2 windows
> they must belong to the same thread.
>
> Otherwise you are pretty much guaranteed a deadlock, unless you only
> ever use MsgWaitForMultipleObjectsEx to synchronise. But that's kinda of
> unachievable unless you have written every single line of code yourself.
>
> So you can have threads with separate UIs as long as you don't make the
> windows of one thread the child of another.
>

Every thread that creates a window will get a message queue created and 
assigned (It's then called a GUI thread).
Under normal circumstances your thread will enter an event loop where 
you call the GetMessage/DispatchMessage function pair. GetMessage gets 
only messages from the threads message queue and DispatchMessage 
dispatches only to the windows owned by the thread.

You can get into troubles when you send a message via SendMessage from 
thread A to a window owned by thread B and the event loop of thread B 
does not handle this message (e.g. by having a modal dialog opened in 
thread B). In this case thread A is blocked until the message is 
processed by B's event loop.

SendMessage is often used in code dealing with Parent/Child window 
relations, so the warning above is justified. But as long as your child 
window event loop is not blocked (or some other access to a shared 
resource creates a deadlock) it works.

There is a technical article about multithreaded GUI and Win32 on MSDN. See
http://msdn.microsoft.com/en-us/library/ms810439.aspx
July 27, 2012
Re: Multi-threaded GUI
On Thursday, 26 July 2012 at 17:15:23 UTC, Simon wrote:
> On 'doze every thread can have it's own message pump and 
> therefore it's own UI, but if you have an ancestor/descent 
> relation between 2 windows they must belong to the same thread.

I meant, you can, say, set window text from non-ui thread 
directly and it will probably succeed, while normally the control 
should check and throw if current thread doesn't match ui thread.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home