Conversation

I’ve never understood the “async I/O is too complicated, why can’t we just use goroutines?” criticism of Rust. You can! They’re called threads, and they work great.

150

This Tweet was deleted by the Tweet author. Learn more

Patrick Walton

@pcwalton

Jun 18, 2019

The point is that green threads aren’t that much more scalable than regular OS threads, and most people would be fine with just OS threads.

Replying to

This is the result of an argument between me and a friend over scalability of OS threads. - You can't spawn 10ks threads in OS. - Yes you can! - Oh really? Just try that! - Here you go:

github.com

GitHub - elazarl/10kthreads: Show that handling 10k threads with thread per connection is possible

Show that handling 10k threads with thread per connection is possible - GitHub - elazarl/10kthreads: Show that handling 10k threads with thread per connection is possible

Replying to

and

You can spawn far more than thousands of OS threads. The practical limit on Linux for threads with guard pages is based on the arbitrary max_map_count configuration option, and that's due to the approach to detecting stack overflow rather than the choice of 1:1 vs M:N scheduling.

Replying to

and

Raise that arbitrary limit (there's no memory or performance cost) and the limit on the number of threads with guard pages goes up with it. The next practical limit is address space size due to stack size, but again that's a different design decision and not tied to 1:1 vs. M:N.

5:03 AM · Jun 20, 2019Twitter Web Client

Replying to

and

There's enough address space on x86_64 and arm64 to spawn literally millions of threads with an 8MiB stack mapping anyway. It doesn't depend on overcommit either, since you can implement stacks per the main thread stack by reserving the space and mapping it in as it's touched.

Replying to

and

Well, yeah, but you still allocate in place granularity, right?. RAM is the most expensive real estate you have in your server. The less you use it, the cheaper your are. This is especially true fur long lived connections, where a busy server is expected to keep a few millions..

Show replies

Replying to

and

Also, your staff grows with page granularity, so if your threads are really tiny, e.g., static resource http server, m:n can reduce your mem usage per connection N:M can make concurrent design easier, since you can use per CPU structures and not worry about locks a la

Replying to

(Stack) Forcing cooperative scheduling also had its merits, e.g. for latency below scheduler ticks, it for proving latency bounds. You usually don't have anything else running on the CPU so OS scheduler could be mitigated. N:M has its merits.