Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multithreaded toolkits: A failed dream? (2004)

weblogs.java.net

Post reply on HN
Print view View original

11–20 of 64 posts

Re: Multithreaded toolkits: A failed dream? (2004)

#11

Post by mpweiher »

wrl wrote: post #7

A big reason why multithreaded UI doesn't work is that the platform code (win32, cocoa) generally has poor support for interacting with OS objects from multiple threads. For instance, NSView instances can only be operated on from the main thread ( https://developer.apple.com/library/mac/documentation/Cocoa/... ). Handling OpenGL context access from multiple threads is terrible, too. I'm quite excited about the additi…

> For instance, NSView instances can only be operated on from the main thread

Cocoa is the toolkit, not the OS, so this is just Cocoa taking exactly the approach described in the fine article.

Re: Multithreaded toolkits: A failed dream? (2004)

#12

Post by Arnt »

Animats wrote: post #2

Photon, the old GUI for QNX, supports some degree of multithreading. You can update the values of various display elements such as meters, progress bars, and text displays from other threads. That GUI is often used for control panels, with real-time data coming in that needs to be current on the display, which is why they made that work. It's going to be interesting to see what happens when someone implements a new G…

I don't remember discussing either of those while writing Qt.

Rather, single-threading followed from two big points. First, the user calls the program rather than the other way around, and the user isn't multithreaded. Second, there aren't performance problems with the UI, and certainly none that require fighting #1.

Some programs need more than one thread. But that need does not originate within the UI, and complicating the UI for it would comply with RFC 1925 point 5.

Re: Multithreaded toolkits: A failed dream? (2004)

#13

Post by AndrewDucker »

frozenport wrote: post #10

Well, its also a poorly motivated dream unless you have a sexual fetish for the Java style of abstraction where everything is completely independent. Who the heck wants multi-threaded GUIs? User interaction proceeds sequentially, so most objects don't require locks. The rare exceptions in my software is rendering or IO on a separate thread, and these don't nicely fit abstraction models, as mentioned in other posts th…

You want a multi-threaded GUI when it's running a long task. Otherwise it won't update until it's finished running, there's no way to cancel the task, etc.

Re: Multithreaded toolkits: A failed dream? (2004)

#14

Post by panic »

AndrewDucker wrote: post #13
frozenport wrote: post #10

Well, its also a poorly motivated dream unless you have a sexual fetish for the Java style of abstraction where everything is completely independent. Who the heck wants multi-threaded GUIs? User interaction proceeds sequentially, so most objects don't require locks. The rare exceptions in my software is rendering or IO on a separate thread, and these don't nicely fit abstraction models, as mentioned in other posts th…

You want a multi-threaded GUI when it's running a long task. Otherwise it won't update until it's finished running, there's no way to cancel the task, etc.

You don't need a multi-threaded GUI for that. You can have the GUI running on one thread while the task runs on another.

Re: Multithreaded toolkits: A failed dream? (2004)

#16

Post by Arnt »

frozenport wrote: post #9
asgard1024 wrote: post #8

What about functional reactive programming? And what about flux pattern? Didn't these resolve this "failed dream" of multi-threaded GUI update? (I am asking real, not rhetorical, questions.)

Don't see how this has anything to do with anything. For example, the "flux" pattern is similar to model/view which can be done by a single thread (ie, Qt). In this scheme the main thread services events sequentially, calling the necessarily object's methods on the same thread. The discussion is about the 'dream' of pushing a button from a worker thread.

The thing is that the entity that pushes a button is a human, not a worker thread.

Re: Multithreaded toolkits: A failed dream? (2004)

#17

Post by asgard1024 »

frozenport wrote: post #9
asgard1024 wrote: post #8

What about functional reactive programming? And what about flux pattern? Didn't these resolve this "failed dream" of multi-threaded GUI update? (I am asking real, not rhetorical, questions.)

Don't see how this has anything to do with anything. For example, the "flux" pattern is similar to model/view which can be done by a single thread (ie, Qt). In this scheme the main thread services events sequentially, calling the necessarily object's methods on the same thread. The discussion is about the 'dream' of pushing a button from a worker thread.

I thought than in flux, the worker thread could send "push button" message to the dispatcher and it will deal with it asynchronously. Likewise, the updates to the views are asynchronous (and can be potentially multi-threaded) to the actions that are coming into the dispatcher queue.

Re: Multithreaded toolkits: A failed dream? (2004)

#18

Post by jbergens »

asgard1024 wrote: post #8

What about functional reactive programming? And what about flux pattern? Didn't these resolve this "failed dream" of multi-threaded GUI update? (I am asking real, not rhetorical, questions.)

Flux is like an event model, every change goes through a single dispatcher and in the store(s) the code is single threaded. If you use multiple stores and have multiple components subscribing to them (to paint the gui) you aren't really guaranteed any order of the events, last write wins and the components basically redraws everything inside them for every event.

Re: Multithreaded toolkits: A failed dream? (2004)

#19

Post by jbergens »

Arnt wrote: post #16
frozenport wrote: post #9

Earlier quoted context omitted.

Don't see how this has anything to do with anything. For example, the "flux" pattern is similar to model/view which can be done by a single thread (ie, Qt). In this scheme the main thread services events sequentially, calling the necessarily object's methods on the same thread. The discussion is about the 'dream' of pushing a button from a worker thread.

The thing is that the entity that pushes a button is a human, not a worker thread.

It is very common to have async http requests that "push button" to to say when they resolve.

Re: Multithreaded toolkits: A failed dream? (2004)

#20

Post by 885895 »

sillysaurus3 wrote: post #5
damienkatz wrote: post #4

Earlier quoted context omitted.

Rust prevents races but not deadlocks, which is one of the bigger problems in multithreaded GUI code.

Locks turn out to be unnecessary for multithreaded code. A ringbuffer of messages is only slightly more complex, yet the gains are massive. Both in performance and simplicity. It's possible to manage a ringbuffer without any locks. The trick is to have a counter for the producer thread, and a counter for each consumer thread. Whenever the producer wants to know "Is it safe to add a message?" it takes the minimum of a…

I would like to read more about what you described here. Know of any good articles or open source projects where this is done?
Post reply on HN