
Google proposes user threads for Linux - doener
https://lore.kernel.org/lkml/20200722234538.166697-1-posk@posk.io/
======
justaguy88
"The PDF and video can go pound sand; you get to fully explain things here."

~~~
crmrc114
[https://lore.kernel.org/lkml/20200723112757.GN5523@worktop.p...](https://lore.kernel.org/lkml/20200723112757.GN5523@worktop.programming.kicks-
ass.net/)

Yeah, that reply made me laugh. Never change Kernel mailing list, never
change.

------
m0zg
This sounds like Google Fibers, and it'll be pretty groundbreaking if this
happens. It's basically an elegant, and extremely scalable way to do N:M
threading which obviates the need for async in a lot of cases, and all the
debugging complications that result from that. Your code looks "linear" and
feels "linear". It's easy to debug and understand. Yet you get to have
essentially as many threads as you like within each process, and you have
effective, useful patterns to manage those threads, and reduce the opportunity
to introduce threading bugs.

That'd be one of the most welcome additions to the kernel in years IMO. And
the change is fairly minimal.

------
telotortium
Wow, Google is finally open-sourcing this - it was first presented publicly in
_2013_.

------
pcwalton
Sweet! I've been asking for this for a while. This seems to me the best way to
do M:N threading: with true kernel support.

------
wilsonthewhale
I recall M:N threading being attempted in the past (in some BSD systems, at
least), with mixed results ultimately resulting in a move to 1:1 threading for
most of them.

What's different about this attempt that puts it over the old? An honest
question

------
doener
Via [https://www.golem.de/news/kernel-google-will-user-threads-
fu...](https://www.golem.de/news/kernel-google-will-user-threads-fuer-
linux-2007-149885.html)

------
CraftThatBlock
Can someone explain this a bit more? Is this closer to say Goroutines for user
space, with a light scheduler but handled by the kernel?

~~~
pcwalton
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).

~~~
CraftThatBlock
Thanks, this was really helpful!

------
darthrupert
Oh cool. I've been wondering to myself why the complexities of async cannot be
abstracted into threads instead in an efficient way. I hope this pans out.

------
The_rationalist
What pro and cons does it have versus project Loom?

