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

[panic]

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 → panic]

Sure. 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 → lmm]

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

[frozenport → lmm]

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

[vesinisa → lmm]

> it's exceedingly tedious to program.

C++ programmer detected? ;)

[lallysingh → lmm]

Just have the ability to send closures (std::function) to other threads' message queues. Then you can use inline lambda syntax.