search

rmanoka / async-scoped

A scope for async_std and tokio to spawn non-static futures
117 stars 14 forks source link

Support for user-provided runtime #15

Closed ftelnov closed 9 months ago

ftelnov commented 11 months ago

First of all, brilliant job!

Currently, you use feature gates with private traits. But there are cases, where user would like to implement your traits for their own runtimes or provide a different implementation for, let's say, tokio runtime.

My proposition is: 1) Make Blocker / Spawner traits public; 2) Add init parameter to Scope, which would be a reference to implementor of those traits.

Honestly I don't see any value in feature gates, as they limit the functionality of the crate. If that's for Rust limitations bypass, describe them please. If it doesn't sound for you, please tell me why. If it sounds great, I'd be happy to implement the proposition!

ftelnov commented 10 months ago

@rmanoka Please, take a look at #16 for an implementation and review

rmanoka commented 10 months ago

Nice work @ftelnov .

I think I'd made the trait private, to ensure we're not violating any rust memory invariants. In particular, I wasn't sure if there's a safe-rust executor, whose guarantees may not match the requirements of this crate, and hence implementing the traits on this executor leads to memory-UB even via safe-rust.

As an escape hatch, I'm okay with making the trait unsafe, and explaining that the user has to prove/verify the necessary things before exposing it via safe-rust.

ftelnov commented 10 months ago

At the first glance at feature gates I realized you actually did it on purpose. Thanks for the explanation! I think we simply can mark the traits unsafe, because it solves the problem and delegates responsibility of necessary checks to the end-user. I also think it's okay from the perspective of unsafe-code pervasivity - in the end, those traits are not being implemented often.

I've added unsafe markers and write yet simple top-level comment about traits unsafety.

But what should be additionally done is invariants definition. What contracts must implementer of these unsafe traits uphold? In other words, what are requirements for the executor? Do we have an example of the dangerous executor?

rmanoka commented 9 months ago

Thanks @ftelnov ; have merged this. I'll release it in the next couple weeks.

rmanoka commented 9 months ago

Released as 0.8.0