Actually, threads are an additional
abstraction on top of a process. So, a thread is basically 'owned' by it's parent process, and all of a processes threads are put to sleep when it is. They seem similar, but they are actually different ideas.
>waifu won't be needing to have a hundred concurrent processes running like a CPU*
Actually, she will. Probably several thousand in fact (every sensor, joint encoder, voltage regulator, airflow switch, etc, etc.) individually
would be it's own process in such an arrangement.
But because they aren't needing to context-switch at all, they can all compete for the available compute resources in a more efficient manner under the hypervisor. And, as mentioned there are other benefits regarding debugging, safety & security potentially to be had as well.
>a complete system freeze should one process get stuck and bottleneck the rest
Actually, a system hang (or crash) is significantly less likely in such an arrangement. Should a unikernel become unresponsive, it's simply rebooted.
>an auxilliary CPU
This is the point behind a cluster. Not only is it a suitable for devising an effective safety-critical failover mechanism, but all the kernels are simply spread out among the available cores (potentially hundreds of them) across the cluster.
This latter point has the potential to significantly reduce performance lags, as the manifold unikernels are all active, all the time. The primary consideration after that is simply communications across the wire.