Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tokio 1.0 – async runtime for Rust

tokio.rs

Post reply on HN
Print view View original

121–130 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#121

Post by sanxiyn »

ksenzee wrote: post #112
sanxiyn wrote: post #106

Earlier quoted context omitted.

async does not make sense for a lot of people and I am deeply worried by hype-driven popularity of Tokio and async-std in Rust. Especially harmful is that common libraries like reqwest (for HTTP requests) pulls async.

Shouldn't an HTTP request library make async available? HTTP is the textbook example for async.

It should, but it shouldn't be the default. Right now, reqwest is the default HTTP request library in Rust ecosystem, and async is mandatory for reqwest. This is a bad situation to be in.

Re: Tokio 1.0 – async runtime for Rust

#122

Post by Groxx »

sanxiyn wrote: post #90
xucheng wrote: post #84

Earlier quoted context omitted.

In a sense, the async API allows you to create green threads. Comparing with the normal threads, which rely on OS schedule and introduce context switches, green threads allow tasks actively yielding the control. This for example can be used to run multiple IO tasks concurrently all in one single OS thread. See https://en.wikipedia.org/wiki/Green_threads

Yes, but why would you want that? Using OS threads is better in most cases.

Most is not all. And some systems (especially embedded) do not have OS threads - they can still make use of green threads / async code.

Re: Tokio 1.0 – async runtime for Rust

#123

Post by nemothekid »

sanxiyn wrote: post #106
ibraheemdev wrote: post #102

Earlier quoted context omitted.

async is not the default. The standard library is 100% blocking, and Rust does not come with a runtime. However, async makes sense for a lot of people, which is why libraries like tokio and async-std are so popular.

async does not make sense for a lot of people and I am deeply worried by hype-driven popularity of Tokio and async-std in Rust. Especially harmful is that common libraries like reqwest (for HTTP requests) pulls async.

Web servers are the quintessential product of async. It’s no surprise that for an industry dominated by web titans spend a lot of time writing web servers and have a huge interest in asynchronous processing. The importance of a sync was cemented way back in 1999 with the c10k problem with nginx vs Apache.

Re: Tokio 1.0 – async runtime for Rust

#124

Post by vvanders »

sanxiyn wrote: post #90
xucheng wrote: post #84

Earlier quoted context omitted.

In a sense, the async API allows you to create green threads. Comparing with the normal threads, which rely on OS schedule and introduce context switches, green threads allow tasks actively yielding the control. This for example can be used to run multiple IO tasks concurrently all in one single OS thread. See https://en.wikipedia.org/wiki/Green_threads

Yes, but why would you want that? Using OS threads is better in most cases.

OS threads cost you stack space, among other things.

There's a reason that most OS native UI frameworks use some sort of event polling structure(WNDPROC[1], Looper/Handler[2], etc) because they're a nice structure for efficient handling of events. Tokio lets you do that across a diverse of events and get the same type of savings.

[1] https://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Wind...

[2] https://developer.android.com/reference/android/os/Looper

Re: Tokio 1.0 – async runtime for Rust

#125

Post by brobinson »

aliceryhl wrote: post #65
brobinson wrote: post #62

Earlier quoted context omitted.

The tokio tutorial is good, but it needs an example of spinning off multiple (2-3 or more) tasks which run forever. I ended up using spawn() multiple times and having the main thread just sleep in a loop and not using #[tokio::main] because I couldn't figure it out.

You can await std::future::pending, or you can just await the Join Handles returned by the calls to spawn.

Thanks for the tip!

Re: Tokio 1.0 – async runtime for Rust

#126

Post by oblio »

varajelle wrote: post #114
akvadrako wrote: post #94

Earlier quoted context omitted.

There are some pretty bad usability problems with most async APIs too. One is they make your functions colored; async functions world best with other async functions while normal blocking functions work best with other blocking functions. They also introduce a lot of noise; putting async/await everywhere doesn't tell you anything interesting. Considering a normal-sized Linux server can handle a million threads withou…

> Considering a normal-sized Linux server can handle a million threads without much trouble, it really seems like misplaced effort Seems like that would use a lot of memory for all the stacks

Based on this, the default value is 2MB: https://unix.stackexchange.com/questions/127602/default-stac...

So that would mean a lot of memory for 1 million threads, 2TB of RAM. But you can change the default. With a 64k stack you'd use up ~68GB of RAM, which doesn't seem like a lot for 1 million threads and 1 million requests happening at the same time.

Re: Tokio 1.0 – async runtime for Rust

#127

Post by sanxiyn »

nemothekid wrote: post #123
sanxiyn wrote: post #106

Earlier quoted context omitted.

async does not make sense for a lot of people and I am deeply worried by hype-driven popularity of Tokio and async-std in Rust. Especially harmful is that common libraries like reqwest (for HTTP requests) pulls async.

Web servers are the quintessential product of async. It’s no surprise that for an industry dominated by web titans spend a lot of time writing web servers and have a huge interest in asynchronous processing. The importance of a sync was cemented way back in 1999 with the c10k problem with nginx vs Apache.

Most people are not writing the next nginx. They are writing web application servers behind nginx.

Re: Tokio 1.0 – async runtime for Rust

#128

Post by brundolf »

sanxiyn wrote: post #110
10000truths wrote: post #105

Earlier quoted context omitted.

OS threads are preemptive and their scheduling is beyond your control, which introduces potential data races. Green threads allow for cooperative scheduling, which is much harder to mess up.

This is moot. Rust prevents data races.

It doesn't prevent race conditions, which may be what the GP meant to say

Re: Tokio 1.0 – async runtime for Rust

#129

Post by sanxiyn »

haberman wrote: post #113
sanxiyn wrote: post #103

Earlier quoted context omitted.

Zig's "colorblind" async is very exciting for this reason: https://kristoff.it/blog/zig-colorblind-async-await/

I'm skimming your link trying to understand the design. It sounds like there is a global flag for whether the whole program is in evented or blocking mode? > during compile-time, it’s possible to inspect if the overall program is in evented mode or not, and properly designed code might decide to move to a threaded model when in blocking mode, for example.

Yes, it's a top level application decision, not a library decision. In fact, this is exactly how allocation and unwinding is handled in Rust.

Re: Tokio 1.0 – async runtime for Rust

#130

Post by [deleted] »

sanxiyn wrote: post #106
ibraheemdev wrote: post #102

Earlier quoted context omitted.

async is not the default. The standard library is 100% blocking, and Rust does not come with a runtime. However, async makes sense for a lot of people, which is why libraries like tokio and async-std are so popular.

async does not make sense for a lot of people and I am deeply worried by hype-driven popularity of Tokio and async-std in Rust. Especially harmful is that common libraries like reqwest (for HTTP requests) pulls async.

[deleted]
Post reply on HN