4 ms·

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 rea

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.)

frozenport 11y ago
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.
- Arnt 11y ago
  The thing is that the entity that pushes a button is a human, not a worker thread.
  - jbergens 11y ago
    It is very common to have async http requests that "push button" to to say when they resolve.
- asgard1024 11y ago
  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.
jbergens 11y ago
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.
- asgard1024 11y ago
  If the CPU bottleneck is on the store, maybe you need some sort of transactional store, where the change is signalled to the views only after a transaction completes? Just thinking out loud. I am not sure what exactly is the original author trying to solve here. But it seems to me that if you want to expand the single GUI thread to multiple threads, for whatever reason, flux and/or FRP may be a good start.

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.)

frozenport 11y ago

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.

Arnt 11y ago
The thing is that the entity that pushes a button is a human, not a worker thread.
- jbergens 11y ago
  It is very common to have async http requests that "push button" to to say when they resolve.
asgard1024 11y ago
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.

jbergens 11y ago

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.

asgard1024 11y ago
If the CPU bottleneck is on the store, maybe you need some sort of transactional store, where the change is signalled to the views only after a transaction completes? Just thinking out loud. I am not sure what exactly is the original author trying to solve here. But it seems to me that if you want to expand the single GUI thread to multiple threads, for whatever reason, flux and/or FRP may be a good start.