search

dbus2 / zbus-old

Rust D-Bus crate.
https://gitlab.freedesktop.org/dbus/zbus
Other
49 stars 13 forks source link

Design considerations around async executors #230

Closed zeenix closed 1 year ago

zeenix commented 2 years ago

In GitLab by @ComplexSpaces on Nov 12, 2021, 22:10

Hey there,

Back on GitHub you had mentioned Zbus was getting closer to an API freeze. This may be a bit late to bring it up, but what considerations were made when designing the async internals of zbus in 2.0? Namely, what influenced bringing in the entire smol-rs ecosystem? This ends up in quite a few extra dependencies (and another whole runtime executor) for projects using Tokio.

The only related things I have seen are this MR and this MR comment. The goal seems to be allowing users to run futures on their own runtimes, but done dynamically instead of at compile time.

Was the approach closer to what SQLx does with compile-time features to change the executor used not considered for complexity reasons, or something else?

Thanks for the consideration.

zeenix commented 2 years ago

This may be a bit late to bring it up

Very much correct. :)

Namely, what influenced bringing in the entire smol-rs ecosystem?

  1. We don't bring in the entire of smol-rs. Just what we need. Also async-broadcast was resurrected by me for our needs so you could say that it's more a part of zbus than smol-rs. Talking of async-broadcast, we couldn't even use tokio's broadcast channels (since they're always leaky) even if we depended on tokio.

  2. Well, it's not exactly an ecosytem but rather more a bunch of nicely sliced crates that provides only a specific feature w/o having to rely on any of the real runtimes (mainly tokio and async-std). If runtimes would have cooperated, this was a good place to do that (other than futures crate) but we can't control what runtimes do and don't. At least async-std uses smol-rs crates.

This ends up in quite a few extra dependencies (and another whole runtime executor) for projects using Tokio.

You're correct to a certain level but I don't think the duplication is that big. The point was to avoid depending on and therefore forcing a specific runtime. Unfortunately that wasn't easy and it comes with a bit of a cost. The alternative would have been to depend on tokio and alienate the async-std apps or the other way around.

Was the approach closer to what SQLx does with compile-time features to change the executor used not considered for complexity reasons, or something else?

I haven't looked at SQLx's API or implementation to know how their needs compare with ours but I can tell you with a lot of certainty that yes, supporting multiple runtimes (w/o duplication) would amount to a lot of complexity and would be quite difficult to achieve in zbus at least. Going through their Cargo.toml files, I did notice that they also have at least some duplication through crossbeam* and futures crates.

zeenix commented 2 years ago

In GitLab by @ComplexSpaces on Nov 12, 2021, 23:38

Thanks for the explanation, it's greatly appreciated.