User space threading?

[andrew-pa]

if most/all processes are going to use async/await and tasks, then maybe it makes more sense to move all threading into user space.
what would this look like?

• no more threads or thread ids
• processes keep track of processor state wrt suspending so the kernel can run
• processes get scheduled in the now process scheduler and have per-process priorities
• processes are the only thing that can exit
• inbox queues either are only attached to processes (1 per) or maybe (this could be an update thing) become their own object if you want more than one?
• new system calls/API:
  • need a way to remember where we were at abstractly perhaps there is still some kind of thread object or token, although idk maybe we just let user space resume wherever it wants (also, stacks need allocated!)
  • need a way to yield anticipating an output
  • need a way to resume with an output
  • need a way to register some kind of scheduler loop that could choose to resume things (probably by checking for messages, but it could also poll device memory or something)
  • it's possible we don't need these to be system calls except for SMP stuff?

hm but yield/resume looks a lot like receive/send... ostensibly these are related but the mechanics would be very different:

• yield would store the current processor state and jump to the scheduler loop and swap to its stack
• resume would load the saved processor state

Fortunately this wouldn't massively affect anything already built on top of async/await since it's just an implementation detail.

Benefits:

• performance?
• simpler kernel, tracks slightly less state
• slightly more complex but less awkward user space
• moves more policy to user space (nothing stopping a process from having a radically different policy)

Questions:

• how would SMP work? maybe you could request another core to start in your process for some task? basically this means kernel threads become fibers
• is this actually more efficient?