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

201–210 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#201

Post by mleo »

sanxiyn wrote: post #159
tijsvd wrote: post #146

Earlier quoted context omitted.

I had the same thing initially. The upside of async over a simple event loop is, in my experience, when things become less simple, and you end up with hard-to-read little state machines all over the place. With async, you can have your event loop, but the state machines are handled by the compiler. Code is like threaded code. That can be very convenient. Threads, obviously, accomplish the same thing, and arguably mor…

> A non-async function is "regular logic", it must complete without blocking. Maybe one can enforce this convention in the particular project, but there's no ecosystem-wide consensus on this, and in fact I don't want this to be consensus. I write blocking non-async functions every day. Why am I wrong to do so?

I believe the idea is that within a project that uses async functionality, you should only use non-async functions when the logic does not call blocking functionality. If you are mixing async functionality and synchronous functions with/blocking I would consider the latter a defect unless it is handled properly within an asynchronous context.

Re: Tokio 1.0 – async runtime for Rust

#202

Post by victor106 »

pvorb wrote: post #170
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…

In the Java world, project Loom[1] is hopefully going to end this situation of async code that is hard to use with blocking code. They introduce a concept called Virtual Threads (previously called Fibers, but they are still looking for the perfect name). This will allow for seamless interoperability between blocking and non-blocking code as everything in Java runs on a Thread and Virtual Threads are just a specializa…

Loom is going to be a game changer. Hopefully they release it soon.

Re: Tokio 1.0 – async runtime for Rust

#203

Post by josephg »

Scarbutt wrote: post #152
ibraheemdev wrote: post #119

Earlier quoted context omitted.

If you think OS threads are "better" than async tasks, then use them. Other people want to use async, so they use it. Rust does not have a runtime and provides blocking APIs by default, but gives you the option to use async if you want to.

True, but everyday more and more libraries are getting tedious to use in blocking mode.

In rust you can block your thread on the completion of an async future. Let other people use async code if they want to, and you can write your code in a syncronous blocking kind of way.

Re: Tokio 1.0 – async runtime for Rust

#204

Post by secondcoming »

sanxiyn wrote: post #127
nemothekid wrote: post #123

Earlier quoted context omitted.

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.

Maybe in your world!

Re: Tokio 1.0 – async runtime for Rust

#205

Post by jandrewrogers »

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 have a high real-world cost that limits throughput, and some things are much simpler to design in an async architecture generally. Context switching is expensive on modern systems, due to both CPU cache thrashing and implied resource cost. In many server applications the CPU will spend more time context switching in massively multithreaded architectures than actually running application code. An async architecture can complete tens of millions of independent operations per second in practice; the OS would have a difficult time just context-switching at that rate even if it was doing nothing else.

Furthermore, some classes of major macro-optimizations can't be implemented effectively if you do everything with kernel threading. This is the reason most modern server software architectures tend be thread-per-core pure async with no real multithreading per se -- it is for the performance.

At a more practical engineering level, these architectures are not more complicated, just different. Some things are much simpler to design because most multithread coordination problems go away. It is nice to be able to write virtually all of your code in single-threaded style where you don't have to worry about locking and consistency, especially as concurrency increases. On the other hand, you have to learn how to design schedules because the OS will no longer be doing that (poorly) for you. It isn't free in that you have to develop expertise in things you may not know but it is often worth it.

Re: Tokio 1.0 – async runtime for Rust

#206

Post by steveklabnik »

btrask wrote: post #191
steveklabnik wrote: post #182

Earlier quoted context omitted.

I mean, it is, yes. That post is talking about threads. And the “fearless” name meant that it solves a lot of issues at compile time, which it still does in an async context. Like any static analysis, it’s a give and take between making sure your analysis is sound, while still allowing useful programs.

Whether it's kernel threads or green threads, the same patterns (locks, etc) are possible. Locks are supposed to be the borrow checker's bread and butter, because it can guarantee they are held before accessing shared state. But now you're saying "the borrow checker makes writing code without [async/await] difficult, inefficient, and unergonomic." I'm not saying locks are better than async/await (although they are[1]…

I am not saying that the borrow checker cannot handle locks. Locks work great.

(The borrow checker does not understand locks as a special construct, to be extra clear.)

Did you read the post I linked? It lays out the details. I am happy to clarify if you don’t get the specifics.

Re: Tokio 1.0 – async runtime for Rust

#207

Post by FridgeSeal »

Xevi wrote: post #169
rossmohax wrote: post #37

It is unfortunate, that libraries have to be coded against specific runtime and not generically. There is tokio and there is smol (likely discontinued, since author left rust), maybe other runtimes will emerge, but whole ecosystem is already tied to tokio.

Woah, I didn't know about that. Does this mean Rust only has one maintained runtime now? Namely Tokio.

Async-std is still actively maintained and developed.

Re: Tokio 1.0 – async runtime for Rust

#208

Post by anarazel »

pas wrote: post #68
seeekr wrote: post #4

They mention working on using io_uring for filesystem calls for 2021. I wonder if there will be an option to use io_uring (instead of epoll) for networking calls as well? Handling network packets and events completely in userspace should allow for lower latency due to no more context switches to and from the Kernel, right?

Both epoll and io_uring depend on the kernel to do the "actual IO", if you want really user-space you need DPDK and a userspace network stack (for TCP/UDP). Both epoll and io_uring have virtually the same performance. Of course uring is a lot more "ergonomic" that's why it already has amazing momentum.

You can do network IO completion notification, instead of readiness notification with io_uring but not epoll. Which avoids the need for a separate syscall that needs to copy memory into the userspace buffers. That can be noticable.

It should also, at some point, allow for nice zero copy network receive paths under the right circumstances (i.e. the network card DMAing directly into the userspace buffers, without very weird setup/high op overhead).

Re: Tokio 1.0 – async runtime for Rust

#209

Post by earwaxauditor »

jedisct1 wrote: post #143
ibraheemdev wrote: post #45

Earlier quoted context omitted.

Since when did Stjepang leave Rust?

He switched to Go. Stjepang is a very smart person and I'm actually quite excited about what he's going to bring to the Go world.

Rust/Go really are the Emacs/Vim of programming languages: little in common but commonly mentioned in the same breath.

Re: Tokio 1.0 – async runtime for Rust

#210

Post by lights0123 »

simias wrote: post #77

I don't really get these modern async APIs. In languages like Javascript I thought they only made sense because JS interpreters are (historically) single-threaded, so you really have no choice but async to express some concepts. Fine. But in Rust you can just spawn threads, share data through channels or mutexes, use OS-provided async IO primitives to poll file descriptors and do event-driven programming etc... I tri…

A very useful thing is that async stuff is easily cancelled in Rust, not so much threads—just making it go out of scope causes it to be cancelled in Rust, while you'd need to add cancellation logic to threads.
Post reply on HN