writing a library that can be reused across many runtimes

[nikomatsakis]

• Character: Barbara
• Brief summary: Barbara tries to write SLOW in a way that it can be used across runtimes; she tries various approaches, none of which are fully satisfactory
• Key points or morals (if known):
  • Writing a library that is generic across libraries is often possible but difficult
  • Feature flags is one option, traits are another
  • Wants to find solutions that are zero-cost
  • Most common features needed are async-read, async-write traits, timers, spawning, opening UDP/TCP sockets
• Conversations:
  • recent Zulip conversation

[AldaronLau]

@nikomatsakis Though it's not necessarily "zero-cost", I think the "crossterm" crate with async enabled has an okay approach that should be mentioned here. It essentially starts a background thread (the not zero-cost part) that sleeps most of the time, which lets the futures know when they're ready. After the thread has started, I believe the costs are relatively low, and acceptable for most projects.

[nikomatsakis]

@AldaronLau that's great, thanks! Another approach worth citing (though it has limitations) is the agnostik crate. From what I can tell, it supports spawning tasks primarily. It is a facade model, where feature flags are used to select which runtime it will use, and the dispatch is done via impl Trait.

I don't know if there are people with real-life experience using the crate to talk about.

Some of the pros I can see theoretically are:

• Code against a single interface
• Lets application crates pick the executor they want without any kind of dynamic dispatch

Some of the cons I can see are:

• Doesn't describe timers, nor the ability to open sockets, I haven't looked at the interfaces to know how hard that would be to include
• Effectively imposes a kind of "global runtime". So if I as a user code my library against the agnostik crate, people can retarget it by specifying feature flags in their application crate, but if they want to use my library with both tokio and async-std, or with some runtime that is not supported by agnostik, they cannot.
• Your clients have to know to specify the feature flag in their Cargo.toml if they care. This doesn't seem so bad.

[AldaronLau]

@nikomatsakis cool, I didn't know about that crate! Now I'm wondering if similar to agnostik, there could be something like std::alloc::GlobalAlloc, called something like std::executor::GlobalExecutor.

The docs say it:

can be used with every executor provided by agnostik, or you can integrate your own executor with Agnostik.

which makes me think it's already pretty close to working like std::alloc::GlobalAlloc.

[ibraheemdev]

There have been proposals for a global_executor in the past:

• https://without.boats/blog/global-executors/
• https://internals.rust-lang.org/t/global-executors/11295

There has also been discussion about an extension to Context that would allow futures to interact with their environment:

• Custom Future contexts rfcs#2900 (comment)
• RFC: Generic member access for dyn Error trait objects rfcs#2895 (comment)

Both of these would make writing runtime-agonstic libraries much easier, but there haven't been any conrete proposals that I know of recently.

[nikomatsakis]

Collecting links is good, but I'd like to focus for now on the challenges -- what is difficult now (and what works well now)? I'd like to hold off on exploring solutions because that quickly gets into the nitty gritty.

One thing that could be really useful though is to look through for the counterarguments to a global allocator and make sure we spell those out. We want to be describing the constraints and considerations for whatever solution we wind up with. (My personal opinion is that a global allocator may be part of that, but I'm not sure, and we will want to be careful whatever we do that we leave room for services that have multiple runtimes interacting.)

[dlight]

The story I would like to see for async Rust is not just to be possible to write cross-runtime libraries, but for it to be the easiest, preferred route: if everybody has access to APIs that abstracts away most differences between runtimes, people will have little reason to directly or indirectly depend on tokio if they are writing a library. It adds more time to the build, for one.

There's another, more philosophical reason to dislike special-casing executors in libraries: perhaps the one we will end up using isn't written yet. So even a library like agnostik that abstracts away N executors (currently, N = 4) isn't enough: I hope we write forward-compatible libraries, so they will stay fresh as the ecosystem evolves.

[erickt]

For a real-world example - On Fuchsia, we support a single executor and runtime fuchsia_async library. However, in order to more easily share libraries across host and target, we've partially implemented a compatibility layer to fuchsia-async that's built upon async-std. Unfortunately, some of the decisions we made in our API makes it difficult to share across runtimes.

The specific problem I ran into was trying to make a portable version of fuchsia_async::net::fuchsia::tcp. One of the APIs to get a stream of accepted sockets is fn TcpListener::accept_stream(self) -> Acceptor. Unfortunately async-std made a different choice, and uses fn TcpListener::incoming(&self) -> Incoming`.

I could probably change fuchsia-async to match async_std's interface, but it looks like tokio's equivalent accept stream takes ownership over the listener with it's TcpListenerStream::new(TcpListener), so there really isn't a standard API in the ecosystem.

[Stupremee]

Hey 👋 ,
I'm the maintainer of the agnostik crate and just stumbled across this thread.
The crate was originally developed to only allow agnostic spawning of tasks, however, we never really started using it which
is the reason it got kinda stuck and really inactive. It's also in general not really well designed could definitely be overhauled.

I would love to rewrite it, also including abstractions for other stuff like sockets, if there's interest. It would probably make a good "playground" for testing executor agnostic ideas. However, I was, and still am, stuck on a good design to have an agnostic runtime. Global spawn (and friends) methods are really helpful, but then you'd only be able to have one active runtime.
Passing a Runtime struct everywhere would also be really annoying to use I think.

So I'm open for any suggestions on how to make the User API and design better.

[nikomatsakis]

@Stupremee thanks! I think that brainstorming what such designs might look like is exactly what I hope to do during the "shiny future" period that is coming up. Maybe we can schedule a time to talk about this.