Explicit future construction, implicit await

[rpjohnst]

That idea came up in the main RFC thread and was decided against (@aturon’s “partial application” framing). It breaks down when you look at async closures that take arguments, because it starts “mixing layers.” Async closures can’t implement Future in general, because they don’t have their arguments yet.

It breaks down even further under this proposal, where async blocks are the only way to obtain a future for async code. Special-casing zero-argument async closures could work (as it could under the main RFC), but it’s not great- especially if its FnOnce impl uses block_on instead of just constructing the future, which would mean some_async_closure() blocks the event loop instead of being awaited.

It is interesting that async || { .. } looks more like something whose body is deferred. And @CAD97’s point of decoupling the async calling convention from the Future trait is also interesting- it would allow for things like the CPS transform I mentioned as a future expansion. But that can be done without removing async blocks.

[MajorBreakfast]

The implementation of () can simply be futures::block_on(self)

block_on() is also not the only executor you could choose. There is I think no obvious default choice that works for all use cases. For example spawn_with_handle() is also great, it runs the future on another thread from the pool.

[kirillkh]

I like the proposal.

One thing that caught my attention, though, is how async { ... } seems to be the main semantic difference from Kotlin. In Kotlin, when you want to create a fresh coroutine context, you would launch { ... }. The main difference is that launch's argument would start executing immediately, as opposed to on demand like in this RFC. Kotlin’s way seems better precisely because of the problem that has been mentioned many times already: it’s easy to forget that you need to start it with block_on(future) or some other way. Ironically, at least one person has already been confused by that even in this thread. So I would prefer to keep the semantics faithful to Kotlin in this instance by making async { ... } start execution immediately. If it is indeed required to make it possible to get a reference to the future before starting it, it might be better to introduce some other way of doing it, e.g. a macro like future!() or even a specialized keyword like future { ... }.

Perhaps it’s even better to get rid of async {} form entirely and, following Kotlin’s lead, replace it with two primary entry points: launch {} for asynchronous computations and do_blocking {} for synchronous.

[CAD97]

Rust has already pretty much decided that its Futures are lazy in the sense that they don’t do anything unless polled/awaited. There are benefits to that, one of which is simplicity of cancellation, one of which is agnosticism to the executor, one of which is ability to run without allocating, and most of which you can read more about over at the main RFC for futures.

In a higher level language, I don’t disagree that immediate scheduling makes for a better environment (for at least some presentations). But it doesn’t fit Rust’s futures model. That’s why my exploration focuses on the deferred behavior and making that obvious.

[rpjohnst]

To be a bit more specific, from the point a Rust future is first polled, it is allowed to contain references to itself. (This is because the future is essentially a stack frame, and stack frames can contain pointers to other values on the stack frame.)

However, a self-referential value cannot be moved, because those pointers would still point to its old location. This means a future must be moved to its final location in memory before it begins execution.

The problem, then, is that a launch { .. } construct would have to be the thing responsible for selecting the future’s final location. If every individual future were always heap-allocated, this would be fine- launch could do the allocation and all would be well. In fact, this is how C++ coroutines work.

But in Rust, we don’t want every individual future to be a separate allocation- while top-level futures will usually be heap-allocated, sub-futures should be stored directly in their parent futures. And in #![no_std] applications, top-level futures will be stored somewhere other than the heap.

So while I do like the way Kotlin handles things with launch and async, I don’t see how that could be made to work in Rust without losing out on the ability to a) borrow local variables in async fns, or b) combine a whole tree of futures into a single allocation.

[repax]

Perhaps async blocks should be implicitly marked as #[must_use].

[MajorBreakfast]

Perhaps async blocks should be implicitly marked as #[must_use].

@rpjohnst’s proposal introduces async {} blocks as a “syntax for constructing a future” (like in the main RFC). Consider voting for must_use for futures in my comment in the RFC.

[H2CO3]

Shouldn’t both the definition and the usage be explicit?

However, we already have an un-annotated operation that can do the same thing: a normal synchronous function call!

Yeah, sure, but

1. await is not a normal synchronous function call.
2. in async code, most functions are expected to be async, so marking the exception (quasi-blocking) is a Good Idea™.

Personally I’m still not convinced that async/await is a good idea at all

This, this this. Especially not hard-wired into the core language. Granted, there are people who might find it easier/nicer than explicit futures. That in itself is not a very strong argument to compensate the burden of a (major) new language feature.

[kirillkh]

But in Rust, we don’t want every individual future to be a separate allocation- while top-level futures will usually be heap-allocated, sub-futures should be stored directly in their parent futures. And in #![no_std] applications, top-level futures will be stored somewhere other than the heap.

Some thoughts on possible solutions.

First of all, let’s separate the two cases of spawning a fresh executor context and achieving concurrency inside an existing context. In Kotlin, the former is called launch, the latter async, but async in this RFC means something else (when used as a modifier in function declarations), so I will use spawn in place of Kotlin’s async. According to you, it is okay to allocate launch's memory separately. So we only need to figure out how to manage spawn's memory.

While I don’t have a well-formed idea on how to solve it, here are some questions:

1. Why can’t we implement self-pointers in a special way that would update them whenever self is moved? That would obviously introduce some overhead at runtime, but would not require external allocation. Of course, the language and/or standard library would have to be extended in some way to support it. So I realize it’s not simple and I’m not saying it’s necessarily a good mechanism for spawn, but has the idea been seriously discussed?
2. Can we allocate the memory non-locally in order to support the majority of use cases? E.g., we could allocate it in the stack frame corresponding to the outermost lexical scope, i.e. the function scope. This is an idea, I’m not sure it’s really doable. Certainly becomes more difficult if spawn is called inside a loop or from a recursive closure. So this is just a starting idea for conversation.
3. Can we require the user to provide us with some way to allocate memory for every call to async? E.g.:

struct JobsPool { /* vec-based ... */ }

trait JobAllocator<T> {
    fn alloc(&mut self, future: Future<T>);
}
impl JobAllocator for JobsPool {
    /* alloc() creates a job and pushes it to the vec ... */ 
}

async fn foo() {
    let jobs = &mut JobsPool::new();
    for i in 0..10 {
        // this form of `spawn` takes a mutable reference to `impl JobAllocator` as an argument
        spawn(jobs) { /* ... */ }
    }
    jobs.join_all();
}

[CAD97]

Yes, offset pointers for movable self references have been discussed before (though I don’t have any links right now). They’re basically confirmed a non-starter because Rust relies on the fact that moving a structure is just a memcopy – there is no such thing as a move constructor in Rust.

Because once a future is started it must be pinned, the only way to make combinators zero cost is to allow you to move in the child futures, thus they cannot be started yet. Thus we can’t start futures until we’re ready to drive them to completion.

[Ixrec]

And before anyone asks “why don’t we add move constructors so offsets can work”, regardless of all the problems move constructors introduce, that still wouldn’t give us a general solution to the generators problem. See the “Offset-based Solutions” section of https://boats.gitlab.io/blog/post/2018-01-30-async-ii-narrowing-the-scope/ (in fact, just read that entire series of posts while you’re there)

[matklad]

An interesting discussion of this issue is happening in the structured concurrency discourse: https://trio.discourse.group/t/structured-concurrency-in-rust/73/10

[Matthias247]

I’ve just seen this proposal for the first time (through the structured concurrency forum link).

I actually think the proposal has buried a very important aspect, which wasn’t really discussed: The different between async functions with run-to-completion semantics and the currently proposed futures. This aspect is somewhat orthogonal to the whether awaits should be implicit or explicit.

I have elaborated a bit on the structured concurrency forum on what is the difference between those things are, and what kind of zero-cost-abstractions it enables.

What seems to be missing in this proposal here seems to be a manually implementable Future type, that also provides run-to-completion guarantee, in order to exploit the system manually. Potentially that you would require two Future types:

• One that has also run-to-completion semantics, is always pinned and will never get dropped before Poll::Ready.
• An always cancellable one, which might work fine without Pin.

[withoutboats]

I don’t see how you could guarantee (in a typesafe sense) that a future will be run to completion since the executor not only must not drop it, but also must continue polling it for it to make progress. Such a guarantee can’t be encoded in any kind of adapter type, as far as I know, only directly on the executor’s spawn API (which would just assert through documentation that it will continue polling the future it receives until it the future is ready or the program halts). Most executors guarantee this already, of course, so I assume you mean some sort of WillComplete adapter, which I don’t think is possible.

Also its important to note, in regard to your longer post you linked to, that futures can only be cancelled at points where they yield a NotReady, allowing the implementer of each future full control over the atomicity of its operations. And while its not guaranteed that a hard cancelled future won’t be leaked all well behaved combinators and executors will drop futures they stop executing, allowing some amount of clean up on cancellation in correctly implemented code.

[glaebhoerl]

but also must continue polling it for it to make progress

FWIW (and IINM), I don’t think “hanging onto it without polling it” is a safety issue any more than the possibility that the OS scheduler might completely starve any given thread? It doesn’t cause UB or even inconsistent-state issues, just… other kinds of problems.

[Matthias247]

I don’t see how you could guarantee (in a typesafe sense) that a future will be run to completion since the executor not only must not drop it, but also must continue polling it for it to make progress

I haven’t thought about it, but I honestly think it doesn’t matter too much. Executors are rare. There’s maybe a handfull of them required. It’s ok for them to contain unsafe code that holds up certain guarantees. They already do that today, by implementing wake() in an unsafe way. Being hold up to the contract to poll each task to completion is just one more addition to that.

And while its not guaranteed that a hard cancelled future won’t be leaked all well behaved combinators and executors will drop futures they stop executing, allowing some amount of clean up on cancellation in correctly implemented code.

It’s not about combinators behaving correctly. It’s about reasoning in async code, and understanding transaction levels. E.g. I wanted to write some kind of rate limiting in async code during the last days. I really wanted to write that in the simple fashion that is equivalent to:

await!(self.async_semaphore.aquire(amount));
{
    /** Do something very long that might yield multiple times */
}
await!(self.async_semaphore.release(amount));

That doesn’t work, since the code might never arrive at release. In a similar fashion an unsafe malloc and a free after a yield point would not be guaranteed to work. In those cases it can be worked around by custom RAII guards. But it’s important to know that those are required, and it doesn’t necessarily work well for other code path where transactional semantics are required but there is not such a notion of guard that can be dropped unconditionally - e.g. if one has to execute situation-dependent cleanup code that also needs to be async.

[withoutboats]

FWIW (and IINM), I don’t think “hanging onto it without polling it” is a safety issue any more than the possibility that the OS scheduler might completely starve any given thread? It doesn’t cause UB or even inconsistent-state issues, just… other kinds of problems.

of course not!

[scottmcm]

In a similar fashion an unsafe malloc and a free after a yield point would not be guaranteed to work. In those cases it can be worked around by custom RAII guards.

I don’t think that’s “worked around”; I think that’s “done properly”. It’s also important that it be done in an RAII guard to be resilient to panics that happen in the middle.

[withoutboats]

The main problem is having an async drop, which cramertj has definitely talked about. Not a near term thing but an interesting extension in the long term.

[Matthias247]

To be clear, the malloc was a simplified example that of course should be wrapped in a proper Rust type. However there are lots of cases where it wouldn’t be that obvious. As @glaebhoerl pointed out in the other thread, making an async task yield/drop-safe is quite similar to making code panic safe. Maybe a bit better highlighted (by await!s), but in comparison to panics also happening in non-broken code, and therefore super-important to get right.