3 ms·

This really hit the nail on the head for me. I'd switch to Scala/Haskell/Clojure if it could give me a multithreaded GUI toolkit, where I'd never have to worry

This really hit the nail on the head for me. I'd switch to Scala/Haskell/Clojure if it could give me a multithreaded GUI toolkit, where I'd never have to worry about whether I was on the event thread or not. Is it impossible? A "Failed Dream"? http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html http://weblogs.java.net/blog/kgh/archive/2004/10/multithread...

pjscott 15y ago
The locking problems that article mentions are a perfect use-case for software transactional memory. Which Haskell and Clojure have. I would wager that someone could make a straightforward multithreaded GUI toolkit in either of those languages. http://en.wikipedia.org/wiki/Software_transactional_memory http://en.wikipedia.org/wiki/Software_transactional_memory
beza1e1 15y ago
A nice overview, unfortunately he stopped before the real insight. 'there is a fundamental conflict here between a thread wanting to go "up" and other threads wanting to go "down"' Can anybody explain that fundamental conflict?
- mooism2 15y ago
  Each level has its own (set of) locks. When a thread goes up/down, it needs to grab a lock from the higher/lower level before it can proceed. When one thread goes up at the same time as another thread goes down and they need the same locks, you get deadlock. Is that what you were asking about, or is there something subtler I'm missing?
  - beza1e1 15y ago
    That is more of a fundamental problem of synchronization than about GUIs. Locks are anti-modular. So one solution could be to abandon locks, which is hardly a fresh insight. An event queue just makes the queue the one and only synchronization point.
jerf 15y ago
I don't think a multithreaded GUI toolkit is a failed dream. But it might take the creation of a GUI toolkit designed from scratch to support it. Though the possibility that some relatively small and clever bit of code could wrap STM around a GUI toolkit is not out of the question.

pjscott 15y ago

The locking problems that article mentions are a perfect use-case for software transactional memory. Which Haskell and Clojure have. I would wager that someone could make a straightforward multithreaded GUI toolkit in either of those languages. http://en.wikipedia.org/wiki/Software_transactional_memory http://en.wikipedia.org/wiki/Software_transactional_memory

beza1e1 15y ago

A nice overview, unfortunately he stopped before the real insight. 'there is a fundamental conflict here between a thread wanting to go "up" and other threads wanting to go "down"' Can anybody explain that fundamental conflict?

mooism2 15y ago
Each level has its own (set of) locks. When a thread goes up/down, it needs to grab a lock from the higher/lower level before it can proceed. When one thread goes up at the same time as another thread goes down and they need the same locks, you get deadlock. Is that what you were asking about, or is there something subtler I'm missing?
- beza1e1 15y ago
  That is more of a fundamental problem of synchronization than about GUIs. Locks are anti-modular. So one solution could be to abandon locks, which is hardly a fresh insight. An event queue just makes the queue the one and only synchronization point.

jerf 15y ago

I don't think a multithreaded GUI toolkit is a failed dream. But it might take the creation of a GUI toolkit designed from scratch to support it. Though the possibility that some relatively small and clever bit of code could wrap STM around a GUI toolkit is not out of the question.