feat: Add anyspawn 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 (a00d17a) to head (cec8d07).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #193   +/-   ##
=======================================
  Coverage   100.0%   100.0%           
=======================================
  Files         105      108    +3     
  Lines        6756     6787   +31     
=======================================
+ Hits         6756     6787   +31     

☔ 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.

[ralfbiedert]

Reviewing

[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.