3

I have been programming Java with swing for a couple of years now, and always accepted that GUI interactions had to happen on the Event Dispatch Thread. I recently started to use GTK+ for C applications and was unsurprised to find that GUI interactions had to be called on gtk_main. Similarly, I looked at SWT to see in what ways it was different to Swing and to see if it was worth using, and again found the UI thread idea, and I am sure that these 3 are not the only toolkits to use this model. I was wondering if there is a reason for this design i.e. what is the reason for keeping UI modifications isolated to a single thread. I can see why some modifications may cause issues (like modifying a list while it is being drawn), but I do not see why these concerns pass on to the user of the API. Is there a limit imposed by an operating system? Is there a good reason these concerns are not 'hidden' (i.e. some form of synchronization that is invisible to the user)? Is there any (even purely conceptual) way of creating a thread safe graphics library, or is such a thing actually impossible?

I found this http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness which seems to describe GTK differently to how I understood it (although my understanding was the same as many people's) How does this differ to other toolkits? Is it possible to implement this in Swing (as the EDT model does not actually prevent access from other threads, it just often leads to Exceptions)

Improve this question
6
  • 1
    I think the Actor model would be a succinct way of creating a thread safe graphics library. One actor per widget or some such. At the OS level though this would probably still have to do literal screen state refreshes in a single thread, possibly only not true in a microkernel system at a guess?
    – Jimmy Hoffa
    Sep 21, 2012 at 14:40
  • I've been experimenting in the last couple of days and already got to one actor per widget (well, actually I went for one per Model, just for the case where one model has multiple widget views). Also discovered that once you start to hit hardware level it becomes difficult to thread graphics - but I was aiming less for actual threading and more an end to constantly having to manually dispatch things, while allowing some threading if not the entire amount I'd like.
    – James
    Oct 8, 2012 at 17:26
  • This is really cool to hear! My gut said this is basically what you would run into when you got closer to the hardware which is why things are usually done this way- often times programmers model solutions based on the hardware behavior which is why graphics libraries tend to be written the way they are (and why learning functional is important for every developer). Did the actor per model really simplify the dispatching you had to do? I'd be interested if this code is open sourceable to see how this worked for you, as I don't know of other UI librarys that take this approach.
    – Jimmy Hoffa
    Oct 8, 2012 at 19:39
  • It seems simpler to me, although it is far from complete in any way. It will be open source, when I have something worth showing. Currently it's less of a library more of a series of experiments (complete with notes on discoveries). Until I'm certain it works though I'm going to keep it private. For the simple cases it certainly seems to be useful, but there are still many things that may cause issues that need a bit of work.
    – James
    Oct 9, 2012 at 16:16
  • weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html
    – assylias
    Feb 11, 2014 at 1:56

2 Answers 2

Reset to default
4

a single looper thread is easier to implement, understand and use compared to multiple threads, (like separate painter eventcallback threads)

because with multithreading in the GUI all access to a GUI component needs to be synchronized (only exception is immutable stuff), this would then become a major bottle neck especially in times where it was prohibitevly expensive to acquire a lock or in tightly coupled frameworks

then there's also that if the eventlisteners can be notified on any thread (whichever one happened to poll the event queue) you would require thread safety to be applied to the underlying model (this is hard to get right). Even the paint-eventcallback segregation example above would need read-write synchronization.

one thing to note is that most frameworks have the idea of a background thread to use for long calculations and IO (like SwingWorker) or atleast a way to add a event to call a certain function on the event thread (generally called invoke)

Improve this answer
2

BeOS implements a GUI via a separate thread per widget, with the result of amazingly good responsiveness on very primitive hardware by modern standards (I noticed very little lag in everyday use of my developer BeBox with dual 66 MHz Power 603s and 64 Mb of RAM back in 1999). Safety of concurrent memory was obviously a major concern and the OS developers did a number of different innovative tricks to keep threads from stepping on one another's memory. This is a nice overview.

Improve this answer
1
  • The only disadvantage being that it's a single user system. Otherwise Haiku OS can be used as a day-to-day desktop OS.
    – user4626
    Feb 11, 2014 at 6:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.