tokio agnosticism

[parazyd]

Hi.

I've noticed that quinn has a mandatory dependency on tokio's sync primitives.
For example here: https://github.com/quinn-rs/quinn/blob/main/quinn/src/connection.rs#L16

For users of smol/async-std it should be possible to avoid this dependency. It would require
an abstraction over these primitives so that when runtime-tokio is requested, the existing
code would be used, or - when runtime-smol is requested - it should be possible to implement
these using async-channel, event-listener, and futures-lite.

This would greatly help projects that use smol and do not want to introduce a tokio dependency,
regardless if it's just the sync primitives.

Is this something that the developers would consider?

[djc]

If someone wants to do the work and it can be wrapped up in a way to avoid complexity in the code libraries, I think we'd be open to that.

[Ralith]

This would greatly help projects that use smol and do not want to introduce a tokio dependency,
regardless if it's just the sync primitives.

Can you elaborate on why that's a useful goal? Is there something wrong with tokio's sync primitives?

[parazyd]

For users who deliberately choose smol for its light footprint, having a mandatory dependency on tokio undermines that choice. Silently pulling in tokio feels like a leaky abstraction and gives off the vibe that the runtime choice isn't fully respected.

Users choosing smol do so to minimize their dependency tree and by forcing tokio this isn't really working out.

smol already has its ecosystem of crates that does everything necessary and when opting into it, you don't really want to use tokio or have to implement shims that make things compatible with tokio's stuff.

[Ralith]

Using tokio's sync primitives with runtime features disabled is very different from using the tokio runtime, and no shims are required to interact with quinn. We don't expose our choice of sync primitives, and even if we did, they don't require shims regardless.

Have you measured an adverse impact on footprint? How large is it?

[parazyd]

I haven't made precise measurements, but on a baseline Tokio's sync module is ~9000 SLOC, while event-listener and async-channel together are ~3000 SLOC.

What's more important is that smol ecosystem users prefer to use smol's ecosystem libraries. And forcing tokio on users clashes with this.

[djc]

If I were a smol user, I'd probably also want to avoid the dependency on tokio. However, as a Quinn maintainer, getting ~700 lines of sync primitives to maintain for a runtime that we don't care for is also pretty unattractive. Perhaps you can get this published as a facade crate maybe called smol-sync-utils or something? Ideally with approval/collaboration from smol maintainers. If we take a dependency on this that means any other smol users that want to use Quinn now also depend on this new crate, so it must look reasonable to those folks.

[Ralith]

forcing tokio on users clashes with this.

To reiterate, Quinn's choice of sync primitives are an implementation detail. Their presence doesn't impact downstream code in any way. If this were not the case, and upstream were not interested in correcting that, I'd be happy to replace them outright.

Trying to transparently swap out two different implementations for nontrivial primitives which almost certainly have different behavior substantially increases the risks of bugs, which would affect downstream code, potentially in subtle ways. The users at greatest risk would be those on the less tested path, i.e. smol users.

I'm skeptical of adding maintenance overhead to increase risk for the very users that might hypothetically benefit from this. If someone can quantify a significant practical benefit, I might feel differently.