The idea is to get the benefits of things like goroutines in a 1:1 framework. The main inherent advantage of userspace threads like goroutines is that you can c

The idea is to get the benefits of things like goroutines in a 1:1 framework. The main inherent advantage of userspace threads like goroutines is that you can context switch between them without going through the OS scheduler. Although the OS scheduler is quite efficient, sometimes you know that you want to immediately run some other thread, perhaps because you're passing a synchronous message to it. The reason why you would want this instead of the traditional implementation of goroutines is that it's compatible with existing code. When you buy into an M:N framework you lose compatibility with all existing libraries, because they could use things like blocking I/O, thread-local storage, or signals. The traditional solution to this that e.g. Go uses is to have some OS threads that you proxy all such calls from your userland M:N threads to. This works, but it's slow, and if you forget to use that mechanism you can end up starving your OS threads or worse. With the switchto patches here, you can get the best of both worlds: fast and precise control over thread scheduling from userland and compatibility with existing libraries. Ideally, it'd enable interoperability among different threading implementations: you could imagine that calling C++ or Rust functions from Go goroutines could become as fast as calling Go functions (though you would still have to deal with the small stack problem).