On Thu, Jul 26, 2012 at 12:16 PM, Russel Winder <[email protected]>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. > > > > Hmm... AFAIK it's quite opposite: windows UI is the only UI that > > works in multithreaded environment, it's just recommended to not > > do it, because this feature is inconsistent with other UI > > frameworks, so that you don't get used to wrong programming > > technique. > > I know essentially nothing of Windows, but quite a lot about > AWT/Swing/JavaFX/GroovyFX, GTK+2, GTK+3, PyGTK, PyGObject, PySide, > PyQt4, wxPython, and tkInter. As you say all of these use an > single-threaded event loop to manage all widgets. Fundamentally this is > because there is only one screen and one window manager, and all widgets > need to be manipulated relative to that. Using a single-threaded event > loop is the easiest way of avoid deadlock and livelock given that there > is a shared resource. > > The same message has been learnt in Web servers where the multi-threaded > approach has given way to a single-threaded event loop approach. > > 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. > > As Simon mention, just because the UI is single-threaded doesn't mean > the application is. Exactly the opposite, good UI-based applications are > generally multi-threaded, it is just that there is only one thread > running the UI, all the others handle business logic. > -- > Russel. > > ============================================================================= > Dr Russel Winder t: +44 20 7585 2200 voip: > sip:[email protected] > 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder > 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. -- Bye, Gor Gyolchanyan.
