Not much, because while this IS better, it is Linux-only and Python and Node.js need to support Windows, macOS, etc. It is also pretty different programming model, so it is hard to abstract over using a portability layer.
I’m also not sure if it’s that relevant for node. From what I’m reading, it looks perfect for the likes of Go, where you want to have threads of execution which can block but where those threads of execution aren’t represented by OS threads. From what I can see, node’s programming model fits very comfortably on top of the existing epoll.
FWIW I’m pretty sure the history is (roughly) that C++ programmers at Google wanted to use Go-like concurrency, hence support for user level threading. There are a bunch of CppCon videos about it that may give more color on that.
My thought is that for languages that already made the big investment in userspace threading, it’s unlikely they will rip the scheduler out.
I think this is most interesting for mostly automatically making “regular” threaded languages “just work”. Think: a more powerful language-agnostic gevent.monkeypatch_all()
If my understanding of the Gil problem is correct, this might mean very little to nothing. As far as I understand the problem with the main python interpreter is that a significant number of its internal data structures and functions are not thread-safe.
If such problems were solved we could as well run multithreaded python off regular pthreads.
I have been wondering for years when this would happen. I tried to email the original presenter from the Linux plumbers conference, but he never responded.
This will be a nice addition to the kernel.
Would this be a feature that you can leverage on rust? Most rust frameworks rely on EPOLL right? It would probably take some time for this to tickle down to the frameworks I guess
This wouldn’t be usable for current Rust async runtimes, because this applies to kernel threads and tasks in current Rust async runtimes are not kernel threads. I also doubt it would be adopted quickly, because it would be Linux-only for quite some time.
What does it mean for things like Python asyncio / coroutines or even nodejs?
Not much, because while this IS better, it is Linux-only and Python and Node.js need to support Windows, macOS, etc. It is also pretty different programming model, so it is hard to abstract over using a portability layer.
I’m also not sure if it’s that relevant for node. From what I’m reading, it looks perfect for the likes of Go, where you want to have threads of execution which can block but where those threads of execution aren’t represented by OS threads. From what I can see, node’s programming model fits very comfortably on top of the existing epoll.
FWIW I’m pretty sure the history is (roughly) that C++ programmers at Google wanted to use Go-like concurrency, hence support for user level threading. There are a bunch of CppCon videos about it that may give more color on that.
My thought is that for languages that already made the big investment in userspace threading, it’s unlikely they will rip the scheduler out.
I think this is most interesting for mostly automatically making “regular” threaded languages “just work”. Think: a more powerful language-agnostic gevent.monkeypatch_all()
If my understanding of the Gil problem is correct, this might mean very little to nothing. As far as I understand the problem with the main python interpreter is that a significant number of its internal data structures and functions are not thread-safe.
If such problems were solved we could as well run multithreaded python off regular pthreads.
I have been wondering for years when this would happen. I tried to email the original presenter from the Linux plumbers conference, but he never responded. This will be a nice addition to the kernel.
Would this be a feature that you can leverage on rust? Most rust frameworks rely on EPOLL right? It would probably take some time for this to tickle down to the frameworks I guess
This wouldn’t be usable for current Rust async runtimes, because this applies to kernel threads and tasks in current Rust async runtimes are not kernel threads. I also doubt it would be adopted quickly, because it would be Linux-only for quite some time.