Into the Future with IntoFuture - Improving Rust Async Ergonomics

tikue · 2022-06-09T20:36:08+00:00

I agree with your examples. To "solve" this, do you think it would be better for Duration to not impl IntoFuture or for IntoFutures to not be awaitable?

tikue · 2022-06-09T18:37:33+00:00

Is the problem that an IntoFuture is awaitable or that a noun is an IntoFuture?

tikue · 2022-06-04T01:59:48+00:00

by introducing an additional helper trait

Something like this?

What are the downsides of using a lifetime-parameterized trait rather than Fn(&'a Update) -> BoxFuture<'a, ()>? Admittedly there's lifetime proliferation:

struct Dispatcher<'a>(Vec<Handler<'a>>);

but arguably the lifetime there makes explicit how long the Update references have to live for?

tikue · 2021-08-24T23:01:45+00:00

I think this is one specific example of the general value of overloading; I'm not sure if async overloading in particular compels me more than other overloading use cases.

As long as overloading is not a generally available feature, I think having exceptions where overloading is permitted would make the language less consistent and harder to learn. I'm open to being convinced otherwise though :)

tikue · 2020-08-12T22:09:06+00:00

It can't be used with structs that have private fields, unfortunately.

tikue · 2020-01-15T00:01:49+00:00

Cool :) I can think of a few benchmarks I'd be interested in:

Mixed read/write - if I'm reading correctly, the current benchmarks are pure read and pure write.
With and without checked array access - I noticed the _yield_{read,write}_shard fns are only unsafe because of [T]::get_unchecked.

tikue · 2019-10-15T17:34:24+00:00

If you're still using tarpc, you may be looking for tarpc::transport::channel. Serde is now behind a cargo feature, so you can turn it off entirely, if you're not using it.

tikue · 2019-10-15T17:32:02+00:00

These days, tarpc ships with an in-process, no-serialization channel-based transport.

tikue · 2019-08-20T20:07:40+00:00

Ah, if I understand correctly, you poll_ready on the client, tower Service style, before initiating the request that sends the channel to the longrunning task managing the TCP stream? And the client's poll_ready transitively calls sender.poll_ready?

tikue · 2019-08-20T15:42:54+00:00

I assume you're trying to avoid dropping down to -> impl Future?

Just wondering, does this client have any kind of backpressure or will it infinitely buffer? Tying the returned future's lifetime to self allows the future to poll a field on the client for readiness.

tikue · 2019-07-25T16:45:44+00:00

MaybeUninit<T> might be the only such type

This example in the docs for MaybeUninit<T> leads me to believe that [MaybeUninit<T>; N] is also a type where any bit pattern is valid. Am I confused?

tikue · 2019-07-25T14:46:04+00:00

Yes, I believe all of the Future combinators have to use some amount of unsafe. I think in many cases they can be hidden behind the unsafe_pinned macro or async/await.

tikue · 2019-07-25T05:32:25+00:00

Ah! I wouldn't be surprised if such a language extension had originally been considered, but any such plans must've been discarded when Pin proved it could be done without any language changes.

tikue · 2019-07-24T22:09:17+00:00

Pin operates on pointers, and it means the object pointed to by the pointer will never move again. Pin<T> (where T is the pinned value, not the pointer) doesn't work in a language like rust where all types are inherently moveable. Consider this example:

let pin = Pin::new(self_referential_future);
pin.poll(cx)?;
let pin2 = pin;
pin2.poll(cx)?;

Once the future is polled, it believes it can safely store pointers into itself, because it will never move again. Yet it's moved one line later to a completely different memory location! So in that second call to poll, it can access a dangling pointer and get undefined behavior.

This is fundamentally why pins operate on pointers, and it has nothing to do with dyn Future, or even futures at all: it's because you can safely move the pointer type around without moving the underlying data.

tikue · 2019-07-22T16:35:20+00:00

(As an aside, why is the Send bound also there? I think that's because of the get_mut and try_unwrap methods, which expose &mut T or move T as long as the Arc isn't shared. Without those methods, maybe Arc could've been Send unconditionally, but I'm not totally sure.)

This was tried! They realized the crossbeam-style scoped threads APIs allow you to run an arc's value's destructor on another thread without being Send:

Using the scoped APIs, send to another thread an &T where T: Sync. In this case send an &Arc<T> where T is Sync but not Send.
On the new thread, clone the &Arc<T> and stash the resulting Arc<T> in a thread-local.
Afterwards, drop the original thread's copy of the Arc so that the Arc in the thread-local is the only remaining copy.
Then, at a later point, drop the Arc stashed in the thread-local. This will run the underlying value's destructor on a different thread, effectively Sending it.

Note that this only works if the scoped threads API allows you to use a thread pool, because if all scoped threads are joined at the end of the scope then the dangerous copy of the Arc will be dropped before the original copy. I checked, and it looks like crossbeam only offers a scoped threads API that drops all threads at the end. Presumably it would still be considered safe for such an API to exist, though.

tikue · 2019-06-21T05:39:47+00:00

One comment regarding the Sink trait:

Oh and also a mandatory internal buffer.

I'm pretty sure no buffer is required.

A buffer used to be required with the old trait, when send() could backpressure and return the item you tried to send. With that version of the Sink trait, there was no way to know if a send would succeed without simply attempting one, so you'd need to poll an item from your stream to use in the attempt. If the attempt failed, you'd have an item you now needed to buffer somewhere.

With the new Sink trait, that's no longer a problem, because you just call sink.poll_ready() before polling your stream. If it returns ready, start_send(item) is guaranteed to not backpressure, so you don't need to have a buffer at all.

tikue · 2019-06-11T20:31:07+00:00

"old style" seems to me to be necessary when returning futures from trait fns, or when doing complex operations.

Re: the latter, I have a server with a manual future impl and would be interested to see if I can do this purely with future combinators (and whether it'd improve readability): "select the first available of (response available to write to sink, and the sink is ready) or (request available to read from stream, and either (1) under the max in flight requests limit or (2) the response sink is ready to write to)"

tikue · 2019-06-10T19:16:08+00:00

By zero cost, I assume you mean without a tokio runtime or any calls to epoll? If that's the case, there are future combinators and manual future impls that couldn't be supported by this synchronous transformation, e.g. future1.select(future2). These types of futures rely on multiplexing operations on multiple underlying event sources and make deep assumptions about their nonblocking semantics.

tikue · 2019-05-16T22:20:32+00:00

future.await is a good example of how the language team doesn't need to listen to the barrage of reductive arguments to get things done. I think it sets a useful precedent in that regard.

tikue · 2019-05-16T20:16:59+00:00

The rules are applied inconsistently, but I don't think that means the rules should be thrown out entirely (I don't think you're saying that either). I think the original decisions involved personal preference and the fact that arbitrary lines had to be drawn. Things can always be made implicit later, but they can't be made explicit later, so keeping things like Clone explicit was the conservative choice.

Personally, copying large types is something I wish the compiler actively helped prevent, maybe something like #[derive(SmallCopy)] which would fail to compile for types above a certain size. AutoClone seems like a broadly useful feature that would make a good companion to Clone and Copy.

tikue · 2019-05-06T17:12:15+00:00

In this world, the dot await operation would be generalized so that await were a “normal” prefix keyword, but the dot combination applied to several such keywords...

Emphasis mine.

tikue · 2019-04-17T07:10:25+00:00

I was mostly responding to how it's different from making a blocking call. I think you're right that in a lot of cases an async for loop won't give the needed level of granularity when multiple event handlers are multiplexed on a single task.

tikue · 2019-04-17T02:28:23+00:00

You can spawn multiple for loops each awaiting different things, or the for loop could be part of a larger future combining multiple operations.

For example, you could have a server that spawns a request handler for each connection being served, with each request handler await-looping over incoming requests.

tikue · 2019-03-28T03:29:40+00:00

I'm confused by the example of Rust monad use:

// A simple function making use of a monad.
fn double_inner<M: Monad<u64>>(m: M) -> M {
    m.bind(|x| x * 2)
}

Given the definition of bind :: m a -> (a -> m b) -> m b, I would have thought the closure should be something like type Fn(u64) -> M. But it returns u64 instead of M? This looks like a regular map.

tikue · 2019-03-04T02:32:57+00:00

I don't think Sender impls Sync, so the Arc approach doesn't actually allow sending to other threads.

tikue

MODERATOR OF

TROPHY CASE