That's not really a good thing, though. You don't need "a thread per window" especially w/ modern async computation, you just need the UI to be in a separate thread from anything that might keep the CPU busy to begin with.
It's probably a very old decision, from times when most desktop computers had one CPU and threads were mostly used to keep GUI responsive while the application was churning data in the background, so there was little interaction between them.
Can you clarify what you mean? You seem to imply that using multiple threads is not a good idea, but then also express that not using multiple threads is also not a good idea. What's left?
There can be many threads per process, but plenty of applications ("Generally") are still single-threaded or even if they aren't, they only use one for the UI.
You can't create 1M threads on Windows (or OS X, for that matter) because there won't be enough RAM for stack space. (also, running more threads than physical cores on CPU-bound task is pretty pointless).
Maybe you mean we should schedule something which has a complete event loop? That would be a lot more fair wrt the Akka version, but the Go version does not create any threads either.
OK, but surely there are cases where it would be useful (I would argue necessary) to have a single process with multiple threads - when dealing with GUIs for example.
Ah that might be able to help bridge the gap for me. I still don’t quite follow, but I guess having multiple threads allows for easier testing of the interface with other components, perhaps? Sorry I am out of my depth on this one. Will Google more tonight
Expanding on this, if you do all the work on the main thread, you're implementing a cooperative multitasking system, with all of the problems that entails.
It's surprisingly hard to break up potentially long tasks in an ergonomic way without losing a ton of performance, tracking down a long tail of tasks that block rendering, or both. Having multiple threads of execution is so much better.
reply