4 ms·
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.
by panic 11y ago
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.
- lmm 11y agoSure. You put a message queue in there and create command objects for all the updates that tasks might want to make to the UI. It's not hard; in fact it's thoroughly mechanical, so it's exceedingly tedious to program. So why isn't the computer doing it for me? I'd happily sacrifice some performance if I could just write the change I wanted to make in the thread where I wanted to make it, and have the computer take care of the bookkeeping.
- devit 11y agoYou can just send a closure to the UI thread and have it executed there, provided you are using a good enough programming language. Or start the long-running computation from the UI code in a way that returns a promise, and chain the UI update on it, in a way that causes that continuation to be scheduled on the UI thread. Or have an UI that can be updated from any thread (but not simultaneously) and take the big UI lock.
- vesinisa 11y ago> it's exceedingly tedious to program. C++ programmer detected? ;)
- lallysingh 11y agoJust have the ability to send closures (std::function) to other threads' message queues. Then you can use inline lambda syntax.
- frozenport 11y agoIn modern frameworks like Qt the message loop is mostly hidden. An astute observer will also note that at the bottom of every Win32 program is a message loop monitoring events such as for when the window is closed.