feat: Add arty crate with generic Spawner trait for spawn tasks for different async runtimes

[schgoo]

No description provided.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.0%. Comparing base (0f5a87c) to head (cc04c3e).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #193   +/-   ##
=======================================
  Coverage   100.0%   100.0%           
=======================================
  Files         106      107    +1     
  Lines        6881     6905   +24     
=======================================
+ Hits         6881     6905   +24     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[martintmk]

Have you thought about applying this guide to spawner?

https://microsoft.github.io/rust-guidelines/guidelines/libs/ux/index.html?highlight=trait#M-DI-HIERARCHY

The idea is that Spawner would be just a normal struct that would expose multiple constructors to create it.

For example:

Tokio:

let spawner = Spawner::new_tokio();

Custom Runtime:

let spawner = Spawner::new_custom(move |future| runtime_handle.spawn(future));

The Spawner would just accept futures of type Future<Output = ()>, but it could also expose additional methods on public APIs that would work with result-returning types. This could be archived by using some oneshot-based async channels.

The downside of this approach is that we would enforce Send and Sync bounds, but this is aligned with https://microsoft.github.io/rust-guidelines/guidelines/libs/interop/index.html?highlight=Send#M-TYPES-SEND.

[schgoo]

Have you thought about applying this guide to spawner?

https://microsoft.github.io/rust-guidelines/guidelines/libs/ux/index.html?highlight=trait#M-DI-HIERARCHY

I can see the value here. I guess the tradeoff would be some additional heap allocations and indirection internally, since the new_custom(...) closure will have to accept a boxed future. Once Oxidizer RT moves here we can add a direct enum variant for it to avoid that additional cost. In fact, we can probably remove this abstraction altogether at that point.

[martintmk]

I can see the value here. I guess the tradeoff would be some additional heap allocations and indirection internally, since the new_custom(...) closure will have to accept a boxed future. Once Oxidizer RT moves here we can add a direct enum variant for it to avoid that additional cost. In fact, we can probably remove this abstraction altogether at that point.

I see the value of this type even when oxidizer rt is public. Sometimes, the library only needs to care about how to spawn tasks and using this type can simplify those scenarios.

[geeknoid]

What's the link between your logo and this crate's use?

[geeknoid]

Why these changes here?

[schgoo]

It was generated by my VS Code markdown extension. It automatically updates the table of contents to match the headers in the file. Should we keep it this way since it's more accurate?

[geeknoid]

I'd rather nuke it, since the first entry in the table of contents ends up being the whole page, which is silly.

[schgoo]

What's the link between your logo and this crate's use?

Throwing the plane was like a fire-and-forget operation, also I had named this "wing" before. It probably isn't as relevant now. In fact, I might use it for uniflight, instead.

[martin-kolinek]

I kinda hoped that arty crate would be the actual runtime, and we could use something more generic for the abstraction layer (runtime-abstraction or something). Not a strong opinion, just feel like arty is a missed opportunity for just the abstraction layer.

[schgoo]

That makes sense. Ralf suggested I use arty. @ralfbiedert what do you think?

[geeknoid]

any_arty?

[ralfbiedert]

@martin-kolinek you mean the ox... umbrella becomes arty? I don't have super strong feelings either, would be onboard with that. I'm not a big fan of runtime-abstraction though, and also not really wing, the former is too long, the latter too unrelated. But let's discuss naming on Teams.

[martin-kolinek]

How does this perform in comparison to tokio::spawn (which already returns an impl Future)? Probably worth a benchmark as we don't want to provide an abstraction that slows things down unnecessarily.

[schgoo]

@martintmk was also suggesting we avoid using oneshot here for tokio, since it already has its own join handle and all that

[ralfbiedert]

Reviewing

[geeknoid]

I was expecting the implementation of tokio support to be just like the Custom type, except that the callbacks are provided by this library instead of by the caller. This would eliminate the need for match here. Basically, make all Spawners custom, but for tokio provide a "built-in custom"

[schgoo]

The benefit of doing it this way is that for tokio we can avoid the performance hit of allocating the future to heap. Although maybe tokio does that anyways, I'm not actually sure.

[ralfbiedert]

I'm not a big fan of run. I rather think your spawn should return its own JoinHandle (defined in arty) which you map for each of your variants.

Also, I am wondering if we should give people on arty already an API to express parallelism intent. Like have spawn and spawn_anywhere (names TBD). The former would make a best-effort to spawn on the same thread, while the latter would make a best-effort not to do that.

[schgoo]

I was originally defining a JoinHandle type here, though that was back when I was also using a Spawner trait, too. Martin Tomka suggested simplifying it in this way. @martintmk any comments here?

[schgoo]

Ok I pushed a version with a JoinHandle. @martintmk is this any better than the way I was using JoinHandle before?

[ralfbiedert]

@martin-kolinek you mean the ox... umbrella becomes arty? I don't have super strong feelings either, would be onboard with that. I'm not a big fan of runtime-abstraction though, and also not really wing, the former is too long, the latter too unrelated. But let's discuss naming on Teams.