<div class="gmail_quote">On Thu, Jul 26, 2012 at 12:16 PM, Russel Winder <span dir="ltr"><<a href="mailto:russel@winder.org.uk" target="_blank">russel@winder.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Wed, 2012-07-25 at 23:17 +0200, Kagamin wrote:<br>
> On Wednesday, 25 July 2012 at 18:50:51 UTC, Simon wrote:<br>
> > You have to be very, very careful with trying to do multi<br>
> > threading w/ windoze windows. Try doing a google search on it,<br>
> > and the advice is invariably: don't do multi threaded windows.<br>
> > Everybody including people famous for their in-depth window<br>
> > knowledge recommends a single thread UI with non-UI worker<br>
> > threads.<br>
><br>
> Hmm... AFAIK it's quite opposite: windows UI is the only UI that<br>
> works in multithreaded environment, it's just recommended to not<br>
> do it, because this feature is inconsistent with other UI<br>
> frameworks, so that you don't get used to wrong programming<br>
> technique.<br>
<br>
</div></div>I know essentially nothing of Windows, but quite a lot about<br>
AWT/Swing/JavaFX/GroovyFX, GTK+2, GTK+3, PyGTK, PyGObject, PySide,<br>
PyQt4, wxPython, and tkInter. As you say all of these use an<br>
single-threaded event loop to manage all widgets. Fundamentally this is<br>
because there is only one screen and one window manager, and all widgets<br>
need to be manipulated relative to that. Using a single-threaded event<br>
loop is the easiest way of avoid deadlock and livelock given that there<br>
is a shared resource.<br>
<br>
The same message has been learnt in Web servers where the multi-threaded<br>
approach has given way to a single-threaded event loop approach.<br>
<br>
So if Windows is really doing multi-threaded widget management, this<br>
would be very interesting.  Where is the material that I can look at<br>
that leads you to say that Windows is a multi-threaded UI.<br>
<br>
As Simon mention, just because the UI is single-threaded doesn't mean<br>
the application is. Exactly the opposite, good UI-based applications are<br>
generally multi-threaded, it is just that there is only one thread<br>
running the UI, all the others handle business logic.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Russel.<br>
=============================================================================<br>
Dr Russel Winder      t: +44 20 7585 2200   voip: <a href="mailto:sip%3Arussel.winder@ekiga.net">sip:russel.winder@ekiga.net</a><br>
41 Buckmaster Road    m: +44 7770 465 077   xmpp: <a href="mailto:russel@winder.org.uk">russel@winder.org.uk</a><br>
London SW11 1EN, UK   w: <a href="http://www.russel.org.uk" target="_blank">www.russel.org.uk</a>  skype: russel_winder<br>
</font></span></blockquote></div><br>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?<div><br></div><div>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.<br clear="all">
<div><br></div>-- <br>Bye,<br>Gor Gyolchanyan.<br>
</div>