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

Async-await on stable Rust

blog.rust-lang.org

Post reply on HN
Print view View original

351–360 of 392 posts

Re: Async-await on stable Rust

#351

Post by littlestymaar »

jstimpfle wrote: post #329
gpderetta wrote: post #325

Earlier quoted context omitted.

because of syntactical restrictions of how await work, at most you need to allocate a single function frame, never a full stack, and often it doesn't even need to be allocated separately and can live in the stack of the underlying OS thread.

So that async function cannot call anything else?

Async function don't really call anything by themselves: the executor does, and all function called in the context of an async function is called on the executor's stack. You just end up with a fixed number of executors running on their own OS thread with a normal stack.

Re: Async-await on stable Rust

#352

Post by pron »

pcwalton wrote: post #338
pron wrote: post #328

Earlier quoted context omitted.

It's isn't a given that M:N threading is slower than 1:1 threading even in Rust. A particular implementation you tried exhibited that behavior. > One has a stack, and the other doesn't. That's a significant difference. They both have some memory area to which they write state. Calling it "a stack" refers to the abstraction in the programmer's mind, not to how the memory is actually written/read. It is true that in or…

> It's isn't a given that M:N threading is slower than 1:1 threading even in Rust. A particular implementation you tried exhibited that behavior. I don't see any way around the problems of segmented stacks and FFI. There is no way to implement stack growth by reallocating stacks and rewriting pointers in Rust, even in theory. It would break too much code: there is a lot of unsafe (and even safe!) code out there that…

You can make what are virtually zero-cost copies from what you call a "big stack" to a resizable stack with virtual memory tricks. You don't even need to copy the entire stack, but cleverly rewrite the return address stored on the stack to do this kind of "code-switching". But it does mean doing backend manipulations in a platform-dependent way. There are several good ways to do this, none of them particularly easy. What is perhaps impossible is allowing FFI code to block the lightweight thread, but async/await doesn't solve this, either.

Re: Async-await on stable Rust

#353

Post by nicoburns »

nirui wrote: post #348
Dowwie wrote: post #62

This is a major milestone for Rust usability and developer productivity. It was really hard to build asynchronous code until now. You had to clone objects used within futures. You had to chain asynchronous calls together. You had to bend over backwards to support conditional returns. Error messages weren't very explanatory. You had limited access to documentation and tutorials to figure everything out. It was a proce…

So I guess the Generic Associated Types should be the next then? I was trying to refactor one of my Rust project the other day and almost immediately got hit by the "No async fn in traits" and the "No lifetime on Associated Type" truck. Then few days later, comes this article: https://news.ycombinator.com/item?id=21367691 . If GAT can resolve those two problems, then I guess I'll just add that to my wish list. Hope t…

They'll probably be a while still as they're quite a complex feature. But they'll be useful for all sorts.

Re: Async-await on stable Rust

#354

Post by jeffdavis »

skocznymroczny wrote: post #344
jeffdavis wrote: post #290

Earlier quoted context omitted.

Ada does have a good ecosystem and community, just not what we'd call modern and mainstream. I looked specifically at Ada, and for my use case macros are quite important. If I were to use Ada, I would need a separate code gen step. I also need concurrency without making new threads. I know Ada can do async but it doesn't have something like tokio. A shame. I wanted to give Ada a try, but didn't get very far before lo…

Have you taken a look at D? It might be what you're looking for. Although I wouldn't consider it mainstream.

I was planning to look more carefully at D if rust didn't work out.

Re: Async-await on stable Rust

#355

Post by ldng »

I would be interested to know if a comparison between async and sync API at level exists. I have this intuitive but probably wrong feeling that async often implies memory overhead.

Re: Async-await on stable Rust

#356

Post by steveklabnik »

monocasa wrote: post #279
steveklabnik wrote: post #260

Earlier quoted context omitted.

Yes. Right now the implementation requires TLS but that will be going away.

To whoever downvoted Steve, he's talking about thread local storage, not transport level security.

Thanks for the clarification! I didn't even notice I was downvoted, and now you're downvoted... I don't get it.

Re: Async-await on stable Rust

#357

Post by monocasa »

steveklabnik wrote: post #356
monocasa wrote: post #279

Earlier quoted context omitted.

To whoever downvoted Steve, he's talking about thread local storage, not transport level security.

Thanks for the clarification! I didn't even notice I was downvoted, and now you're downvoted... I don't get it.

HN be a harsh mistress.

Re: Async-await on stable Rust

#358

Post by jabl »

jstimpfle wrote: post #233
weberc2 wrote: post #207

Earlier quoted context omitted.

Proposing asm and deprecated APIs, "just use a portable wrapper library" as though there are any such (good) libraries, type safety, etc.

The fact is, all "green threads" do is swapping between call stacks and call register sets. The call stack is usually just a register itself. How hard can it be to save a register and restore it later? > as though there are any such (good) libraries Win32 Fibers are extremely easy to use (and not deprecated). I used them once, it was a blast. I wrote a simple wrapper around them in less than 50 lines of straightforwa…

> Win32 Fibers are extremely easy to use (and not deprecated).

Apparently MS is considering depreciating them: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p136...

That's in general an interesting paper about M:N threads, fibers, green threads, or whatever you want to call them.

Re: Async-await on stable Rust

#359

Post by pron »

pcwalton wrote: post #339
pron wrote: post #327

Earlier quoted context omitted.

Sure, but that overhead is also not essential, but a feature of Go's particular implementation. Fibers aren't one thing and there are many, many ways of implementing them. As I said before, implementing them for Rust well would have likely required changes to LLVM and Web Assembly, and even then it would be harder than async/await, perhaps to the point of being too hard to be worth it and probably against aspects of…

> Sure, but that overhead is also not essential, but a feature of Go's particular implementation. The only way to get around the FFI performance problem would be for all fibers to have big stacks. At that point you've thrown away their biggest selling points: high scalability and fast spawning.

> The only way to get around the FFI performance problem would be for all fibers to have big stacks.

I don't know all of Rust's specific constraints, but it is not the case in general. There are two levels for FFI support in this context, based on whether you want to allow FFI to block the lightweight thread (perhaps through an upcall), or not. Only if you want to allow that do you need "big stacks", but even then they can be "virtually big" but "physically small". If you don't, then all you need to do is to temporarily run FFI code on a "big stack", but you know that all the FFI frames are gone by the time you want to block. Depending on your FFI, if you don't allow the FFI code to hold pointers into you language's stack, you're all good.

Re: Async-await on stable Rust

#360

Post by pcwalton »

pron wrote: post #352
pcwalton wrote: post #338

Earlier quoted context omitted.

> It's isn't a given that M:N threading is slower than 1:1 threading even in Rust. A particular implementation you tried exhibited that behavior. I don't see any way around the problems of segmented stacks and FFI. There is no way to implement stack growth by reallocating stacks and rewriting pointers in Rust, even in theory. It would break too much code: there is a lot of unsafe (and even safe!) code out there that…

You can make what are virtually zero-cost copies from what you call a "big stack" to a resizable stack with virtual memory tricks. You don't even need to copy the entire stack, but cleverly rewrite the return address stored on the stack to do this kind of "code-switching". But it does mean doing backend manipulations in a platform-dependent way. There are several good ways to do this, none of them particularly easy.…

> You can make what are virtually zero-cost copies from what you call a "big stack" to a resizable stack with virtual memory tricks. You don't even need to copy the entire stack, but cleverly rewrite the return address stored on the stack to do this kind of "code-switching".

We tried it. It was too slow.

Post reply on HN