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

Async and Await in Rust: a full proposal

boats.gitlab.io

Post reply on HN
Print view View original

81–90 of 196 posts

Re: Async and Await in Rust: a full proposal

#81

Post by gpderetta »

shawn wrote: post #74
gpderetta wrote: post #71

I'm somewhat disappointed that rust is going with async style stackless continuations. I'm a huge fan of stackfull coroutines/continuations as they are much more elegant and flexible. The downside is that they need a full stack, but I strongly believe (but can't prove) that rust has enough annotations and lifetime capabilities that it should be able to guarantee single frame allocation (or even no allocation for full…

Undelimited continuations are memory sieves. Delimited continuations are better but a bit less useful.

Genuine question: aren't all one shot continuations (like the ones this thread is about) naturally delimited? Is there even such a thing as an undelimited one shot continuation?

Re: Async and Await in Rust: a full proposal

#82

Post by gpderetta »

nine_k wrote: post #76
gpderetta wrote: post #40

Earlier quoted context omitted.

I'm not familiar with the way rust is going, but in general Async can be implemented purely a compile time by turning an async function into a set of functions tail calling each other or a switch statement. The stack frame need to go somewhere, but with allocator support this does not need to be exclusively handled by the runtime.

This is likely doable if no I/O is involved in the scheduling of coroutines. Usually it is.

That's completely orthogonal though.

Re: Async and Await in Rust: a full proposal

#83

Post by sametmax »

timClicks wrote: post #79
sametmax wrote: post #41

Earlier quoted context omitted.

Be careful with this. I'm not saying you should not do it, but consider you'll have to design it very carefully. In python you can chose what event loop to hook to async/await, and hence we have gevent, qt, uvloop, twisted, asyncio, tornado, trio and curio as competing implementations. They are very difficult to mix, and their ecosystems are mostly isolated, dividing the man power to add features, fix bugs, provide s…

Concur. Although perhaps the situation in Python could have been mitigated somewhat if a protocol was defined early that implementations could have adopted? Context managers, iterators and decorators all work nicely together, even across language boundaries via the extensions API.

> Although perhaps the situation in Python could have been mitigated somewhat if a protocol was defined early that implementations could have adopted?

Yes. That's one thing the rust community has to get right.

async/await was supposed to be that, but it's only a protocol to define what blocks/doesn't and when you allow context switching. An event loop also has the notion of scheduling, getting a reference to what is scheduled, request the result or error on said scheduled thing, or cancel it. And even loop must bridge different implementations of concurrency (e.g: asyncio.run_in_executor). An event loop also has a life cycle, which includes at the very least a setup and a tear down. An event loop must integrates in an environment, like what do you do when you have several loops, or if you run one loop per threads ?

So you need to define a general behavior for all that. Then let anyone write the implementation the way they want.

Re: Async and Await in Rust: a full proposal

#84

Post by steveklabnik »

sametmax wrote: post #83
timClicks wrote: post #79

Earlier quoted context omitted.

Concur. Although perhaps the situation in Python could have been mitigated somewhat if a protocol was defined early that implementations could have adopted? Context managers, iterators and decorators all work nicely together, even across language boundaries via the extensions API.

> Although perhaps the situation in Python could have been mitigated somewhat if a protocol was defined early that implementations could have adopted? Yes. That's one thing the rust community has to get right. async/await was supposed to be that, but it's only a protocol to define what blocks/doesn't and when you allow context switching. An event loop also has the notion of scheduling, getting a reference to what is…

That’s all of this: https://doc.rust-lang.org/nightly/core/task/

Re: Async and Await in Rust: a full proposal

#85

Post by nine_k »

noobermin wrote: post #27
eikenberry wrote: post #16

Earlier quoted context omitted.

I'm curious as to why you think that matters? Async/Await are general purpose concurrent programming abstractions.

Alright, so I do computational plasma physics simulations for a living. Given our problem sizes often reach sizes which require teraflop level of parallelism to get done before I retire (that's my scale, I'm sure you're aware of petaflop sims the fluid/engineering guys do) we do need concurrency but it's done by chopping up the domain, literally the volume of space we simulate, onto processors. Now, we could possibly…

At worst, you'll have to explicitly wait for all your async calls to have completed and produce results. I suppose normally the implicit wait occurs on attempt to access the result. I also suppose you have to do it anyway in a multi-processor system, and you can't be doing it on a single core.

At best, some of your CPUs would be able to run calculations for two especially fast-to-compute pieces of volume space, while some other CPUs would be busy computing a particularly gnarly block of the volume space.

Re: Async and Await in Rust: a full proposal

#86

Post by vanderZwan »

kbumsik wrote: post #24

As an embedded system dev, I'm wondering if these async features can be implemented on bare-metal (or without runtime)? Maybe I'm dumb and it might be a wild thought but it would be great if I could easily integrate async language features with hardware interrupts.

If you're interested in async features for the sake of concurrency, you might want to give synchronous concurrency a look - Céu is a very recent entry into this paradigm[0]. It specifically targets the embedded space due to its minimal overhead compared to other concurrency solutions. Also, there is a version that supports libuv for added async stuff[1].

[0] http://ceu-lang.org/

[1] https://github.com/ceu-lang/ceu-libuv

Re: Async and Await in Rust: a full proposal

#87

Post by maxxxxx »

imtringued wrote: post #75
maxxxxx wrote: post #67

Earlier quoted context omitted.

They are a real problem in desktop apps when you have to shut down the app gracefully. If you call an async function during shutdown you can't really tell when the async chain is done and you have nothing to wait for. Just dealt with that in a .NET app that uses a 3rd party SDK that heavily uses async/wait. I had to build a whole layer of state management to just handle shutdowns. Simple threading would have been muc…

That just sounds like the API wasn't designed to support async/await rather than an inherent limitation. Something like Promise.all [1] is all you need to wait for multiple promises if the API had a way to accept a promise instead of a synchronous callback. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

The same problem would happen with a promise. In a desktop the user clicks "Quit". If you now have to call an async function the Quit handler will return and somewhen later the await portion of the code gets called. From the Quit handler you can't tell when the await stuff has finished so there is no clear time when you can shut down the app.

In a browser on or server side it's different.

Re: Async and Await in Rust: a full proposal

#88

Post by shawn »

gpderetta wrote: post #61
anko wrote: post #23

Earlier quoted context omitted.

Threading sucks. It's a situation where you have some external process (the operating system) deciding when different pieces of work should be woken up, with no way of feeding this back (so it just bases it on relatively naive schedulers). In practice, most of your threads are in one form of wait loop or another and you've just got polling both inside the threads and with the scheduler. Have a look at Erlang if you w…

You can have userspace threads (or even hybrids m:n threading). They went out of fashion in the last decade for many reasons but were fairly common in the past.

I’m currently implementing threading into an editor scripting language. Could you talk more about this? It would be helpful.

Re: Async and Await in Rust: a full proposal

#89

Post by sametmax »

steveklabnik wrote: post #84
sametmax wrote: post #83

Earlier quoted context omitted.

> Although perhaps the situation in Python could have been mitigated somewhat if a protocol was defined early that implementations could have adopted? Yes. That's one thing the rust community has to get right. async/await was supposed to be that, but it's only a protocol to define what blocks/doesn't and when you allow context switching. An event loop also has the notion of scheduling, getting a reference to what is…

That’s all of this: https://doc.rust-lang.org/nightly/core/task/

That's an API. Like asyncio in Python is an API. If you make the event loop swapable without making this API mandatory however, it's never going to be a protocol.

Re: Async and Await in Rust: a full proposal

#90

Post by jononor »

Nemo157 wrote: post #45
kbumsik wrote: post #24

As an embedded system dev, I'm wondering if these async features can be implemented on bare-metal (or without runtime)? Maybe I'm dumb and it might be a wild thought but it would be great if I could easily integrate async language features with hardware interrupts.

Definitely. We’re currently blocked with the builtin await using thread local storage, but that’s planned to be removed and replaced with something that will work without an OS before stabilisation. I have had the old macro based async code in Rust running on a Cortex M device, completely runtime free. Once the TLS stuff is sorted I plan to port this forward to work with the builtin syntax.

Super excited about that! This will be a major feature for embedded devices which perform network I/O, be it Internet of Things or industrial control over Ethernet.
Post reply on HN