Progress on async fidl

[Raph Levien]

We've been working on making fidl work in a fully async mode, as opposed to the previous hacky prototype where we spawned threads to run a server and also to wait for a response. This is based the Rust ecosystem's preferred async stack, namely futures-rs, mio, and tokio-core.

I have it building locally, and the ledger_example now works. There a few build-related steps to work through to get it building, but I figured people would want to see the code.

https://fuchsia-review.googlesource.com/#/c/fidl/+/45267/

https://fuchsia-review.googlesource.com/#/c/rust_ledger_example/+/45268/

There's also a fairly small "fucsha-tokio" layer that I'm in the process of uploading. I'll update this thread when that's done. In the meantime, I'm hoping that interested people can take a look at the code and see the general approach we've taken. To a large extent, this is a prototype of where we want to be, as we'll be reworking fidl quite a bit in coming months. So the focus now is to learn where the rough edges are, and also be able to meaningfully do performance measurements (not realistic when doing a sync request spawns a new thread). We are seeing more boxing than we'd like, which hopefully will improve with "impl Trait".

Huge shout-out to Taylor Cramer for landing the Fuchsia port of mio, and to Tristan Hume for pairing with me on this work - the commits with my name on them are very much joint work. Also thanks to Alex Crichton and Carl Lerche for releasing the 0.6.10 version of mio with Fuchsia support.

Very happy to answer any questions.

Raph

[Raph Levien]

A quick update on this. The tokio-fuchsia layer (slightly renamed) is now uploaded to:

https://fuchsia-review.googlesource.com/#/c/tokio-fuchsia/+/46376/

I'm still wrestling with build issues (the Fuchsia-aware mio has been released, but not yet with tokio-core, and in any case we need to make in-tree and third party crate references to magenta-rs datatypes point to the same source of truth), but I'm hoping to work through these shortly.

In code review, Taylor brought up the use of the ".boxed" method, and the fact that is enforces the Send bound. I've changed the code to use Box::new instead, which does not. However, the fidl bindings are still in terms of the BoxFuture type, which enforces Send, and that in turn means that we need to use the sync variants of channels (as opposed to unsync) internally for a number of things. This raises some tough deeper questions. Do we want to optimize for the single-thread case (avoiding needless use of atomics) because the current tokio core is single-threaded, or do we want to leave the door open for multi-threaded waiting? In any case, this feels like a question we should tackle later, and the goal for now should be getting something working, ideally so that we can commit more fully to either of these branches later without causing major disruption to client code. (For example, making clients "use fidl::BoxFuture" instead of "use futures::BoxFuture" seems perfectly reasonable).

Hoping to post a working build soon.

Raph

--
You received this message because you are subscribed to the Google Groups "rust-fuchsia" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rust-fuchsia+unsubscribe@fuchsia.com.
To post to this group, send email to rust-f...@fuchsia.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.com/d/msgid/rust-fuchsia/CAFQ67bObu0523ETtxZ1smTntLzLR7oGcGoXi%3DZzCgjx5oSAinA%40mail.gmail.com.

[Alex Crichton]

FWIW we're highly likely to remove `.boxed()` and `BoxFuture` from
futures 0.2, I think they've caused more harm than good :(

In general I've found a good rule of thumb for now is that data types
should be Send when possible (e.g. tokio_core::net::TcpStream),
although future less so. The only use case for a future being `Send`
is to actually send the future itself across threads, which very
rarely happens. In that sense you'd probably be fine just using
`Box<Future<..>>` because most of the time you'll just spawn the
future on a `Core` anyway. That's at least what I've observed now for
now at least!

>> email to rust-fuchsia...@fuchsia.com.

>> To post to this group, send email to rust-f...@fuchsia.com.
>> To view this discussion on the web visit
>> https://groups.google.com/a/fuchsia.com/d/msgid/rust-fuchsia/CAFQ67bObu0523ETtxZ1smTntLzLR7oGcGoXi%3DZzCgjx5oSAinA%40mail.gmail.com.
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "rust-fuchsia" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to rust-fuchsia...@fuchsia.com.

> To post to this group, send email to rust-f...@fuchsia.com.
> To view this discussion on the web visit

> https://groups.google.com/a/fuchsia.com/d/msgid/rust-fuchsia/CADBEgNPgMioZ7Cu0Wz41nzGBu9C7U5Zzg7J3cEqrCTin86xBWA%40mail.gmail.com.