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

311–320 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#311

Post by boulos »

vlmutolo wrote: post #299
boulos wrote: post #293

I'm hopeful that this leads to some focus on the ergonomics of "waiting for async things from sync code". Lots of "handlers" in the universe have synchronous interfaces, so if you want to implement them you end up needing to poll/wait on async from a regular function. I swear that every time I poke at Rust, I seem to find some way to cut my fingers... My specific example is writing a fuse handler (now with cberner/fu…

I've encountered the "wait on async things from sync code" issue several times, too. I have found that something like `block_on` from either `futures` or `futures_lite` often does the trick. https://docs.rs/futures-lite/1.11.3/futures_lite/future/fn.b...

Right, but depending on the tokio version (maybe) using block_on results in a hang or panic. I’ll see if futures_lite is any different, but I think it’s mostly on tokio’s side.

Re: Tokio 1.0 – async runtime for Rust

#312

Post by [deleted] »

slavik81 wrote: post #263
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. What does 'blocking' mean? I would expect the definition of synchronous to be the exact opposite; i.e., a synchronous function must block the caller until the function has finished executing. For that matter, what is "regular logic"? The name implies there is some sort of "irregular logic" to contrast it with. I get the feeling that the wri…

[deleted]

Re: Tokio 1.0 – async runtime for Rust

#313

Post by swsieber »

Cool stuff. There seems to be some cool improvement every several months.

I'm excited for GATs to land so we can have true async trait methods. The async story in Rust has come a long way, but there's still a lot to be improved.

Re: Tokio 1.0 – async runtime for Rust

#314

Post by pat2man »

renewiltord wrote: post #183

Always found these APIs a little hard to work with. For instance, if I tried to use `actix-web`, then using `reqwest` and `tokio` felt like pulling teeth. If anyone's got minimal code lining up a web framework (any one, not stuck to actix) with some reqwest, I'd be thankful to look over it. Just some trivial stuff so I can add an API gateway that proxies a specific API.

Actix web has an example that is basically just a proxy. It does use its own client vs reqwest but the principals are the same.

Re: Tokio 1.0 – async runtime for Rust

#315

Post by chrismorgan »

josephg wrote: post #192
sanxiyn wrote: post #159

Earlier quoted context omitted.

> 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?

There is consensus in some ecosystems. Javascript absolutely maintains that invariant. There are (almost) no blocking functions in the javascript / node standard libraries and we work hard to keep it that way. Go maintains similar discipline at the OS syscall level. I feel like the "what color is your function" thing is incomplete. There are arguably 3 types of functions: - Functions which do all their work synchrono…

I have seen fs.*Sync functions being called deep in async-land more than once or twice in Node.

Re: Tokio 1.0 – async runtime for Rust

#316

Post by ldng »

lmm wrote: post #306
ldng wrote: post #282

Earlier quoted context omitted.

I also don't get the async hype. Maybe it is undesirable because that often times plain mono-thread synchronous is fast enough, easier to read, easier to debug and safe to handle to a junior ? Not everybody in a team has the same level of expertise. And Rust is not an interpreted language. IMHO, interpreted languages should just drop to a compiled one to keep it KISS. Instead of going the async road, just to discover…

> Maybe it is undesirable because that often times plain mono-thread synchronous is fast enough, easier to read, easier to debug and safe to handle to a junior ? Not everybody in a team has the same level of expertise. Shared-memory concurrency is pretty much always buggy, IME, even if your team thinks they're experts. > And Rust is not an interpreted language. IMHO, interpreted languages should just drop to a compil…

Why WTF ?

You are reading something I did not write. I am not obsessed with the nonblocking mantra. Blocking is not inherently bad. Multi-processus is also a perfectly valid concurrency model.

Nor am I obsessing about being ultra performant to achieve the revered C10K when I don't need to or can get around it. That was my point.

Not everybody is Facebook or Netflix. For the vast majority of small and medium enterprises, it faster, simpler, safer (and possibly cheaper) to quickly develop a blocking program without thread and spawn multiple processes.

Re: Tokio 1.0 – async runtime for Rust

#317

Post by tijsvd »

simias wrote: post #165
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…

>Threads, obviously, accomplish the same thing, and arguably more easily. But threads have a performance problem when they must interact heavily. Cross-thread communication is expensive. I didn't know that cross "async" communication was cheaper, that does seem like a good selling point, but what exactly makes it cheaper? After all threads share the same address space, so you can just pass pointers around the same wa…

It's faster than multiple threads even on a single core. There are syscalls involved to wait, and to wake up. That doesn't matter for I/O, since syscalls are involved anyway, but it does for mutexes and condition variables. With async, handing off control to one or more other tasks is cheap (tokio around 100 ns), for threads it's more expensive (2-3 us).

And of course with threads it's harder to actually run single-core, you need to dedicated a specific core which brings operational complexity.

Re: Tokio 1.0 – async runtime for Rust

#318

Post by tijsvd »

slavik81 wrote: post #263
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. What does 'blocking' mean? I would expect the definition of synchronous to be the exact opposite; i.e., a synchronous function must block the caller until the function has finished executing. For that matter, what is "regular logic"? The name implies there is some sort of "irregular logic" to contrast it with. I get the feeling that the wri…

Sorry for the wording, the term blocking is common in network programming.

With blocking I mean waiting. For I/O to complete, for time to pass, or for another task to complete something. In event-based programming, functions must not block. Async functions may seem to block, but they don't rely because a state machine is involved.

Re: Tokio 1.0 – async runtime for Rust

#319

Post by lmm »

ldng wrote: post #316
lmm wrote: post #306

Earlier quoted context omitted.

> Maybe it is undesirable because that often times plain mono-thread synchronous is fast enough, easier to read, easier to debug and safe to handle to a junior ? Not everybody in a team has the same level of expertise. Shared-memory concurrency is pretty much always buggy, IME, even if your team thinks they're experts. > And Rust is not an interpreted language. IMHO, interpreted languages should just drop to a compil…

Why WTF ? You are reading something I did not write. I am not obsessed with the nonblocking mantra. Blocking is not inherently bad. Multi-processus is also a perfectly valid concurrency model. Nor am I obsessing about being ultra performant to achieve the revered C10K when I don't need to or can get around it. That was my point. Not everybody is Facebook or Netflix. For the vast majority of small and medium enterpris…

> Why WTF ?

Because WTF does using a compiled language have to do with anything?

> Nor am I obsessing about being ultra performant to achieve the revered C10K when I don't need to or can get around it. That was my point.

Then what is it that you imagine using a compiled language would help with?

Re: Tokio 1.0 – async runtime for Rust

#320

Post by tijsvd »

wahern wrote: post #271
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…

> Cross-thread communication is expensive. Single-threaded async task interaction is very cheap, comparatively This all depends on how threads are implemented. If they're scheduled preemptively then communication can be expensive, relatively speaking, because of the need for locking and atomic operations. But you can also schedule cooperatively in user space, just as Tokio does when serially resuming async tasks; or…

I agree, it would be great if we could just write threads and not worry about performance. In the end, at least for me, async is a poor compromise between ergonomics and performance.

Unfortunately we're not there yet. Golang with GOMAXPROCS set to 1 comes close, but now I lose the ability to spawn real threads for expensive computation.

Post reply on HN