This can change if OSes start optimizing for the proposed convention.
> It also adds complexity to the build pipeline.
At least in C/C++ it doesn't. But again, this is also easily solvable if we want to.
> You wouldn't spawn a process for the rendering/input/physics/network/job/loader threads of a game engine for one.
Why not? In my mind, if you need 2-way communication between 2 threads, they should be siblings. If they need one way communication, there should be a parent-child structure. If they need no/minimal communication, they are better off as processes. I don't know which categories each of the threads you named fall into. I realize that this approach will require extensive redesign of existing software, very much like the elimination of goto required.
> You can't spawn processes from a web app either.
No reason for it to stay that way.
> Threads are actually pretty darn simple when you have either immutable data or uniqueness constraints. Deterministic parallelism is also very powerful while preventing all sorts of nasty bugs.
I won't pretend to know all those words :P I just think the article's proposal has some merit and we should consider it. >