Closed samchouse closed 5 months ago
Could you provide a minimal reproduction example. A PR for that in form of a unit test would be highly appreciated!
Done #334
Actually I realized that I had something like this setup in Actix and the only difference between our types is this:
- Pin<Box<dyn Future<Output = ()> + Send + Sync>>;
+ Pin<Box<dyn Future<Output = ()>>>;
I guess Send + Sync
is unnecessary in this case however I'm not sure if this is still an issue with the library or the bounds are unnecessary in every case.
The future returned by Pool::get()
is + Send
but not + Sync
.
I do wonder why you need it to be + Sync
? Futures can't be awaited or polled from multiple threads so I wonder why you need it to be + Sync
in the first place?
After removing the + Sync
markers the code compiles fine:
- type ClosureFuture = Pin<Box<dyn std::future::Future<Output = ()> + Send + Sync>>;
- async fn test_closure<T: Fn(String) -> ClosureFuture + Send + Sync + 'static>(_: T) {
+ type ClosureFuture = Pin<Box<dyn std::future::Future<Output = ()> + Send>>;
+ async fn test_closure<T: Fn(String) -> ClosureFuture + Send + 'static>(_: T) {
I'm not very good with async in Rust so I was just slapping Send + Sync
everywhere. Since this is the case, everything seems to be fine with the lib and I'll close this issue. Sorry for the clutter!
Adding Sync
to a Future
doesn't add anything. Quoting @Darksonn from the #tokio-users
channel:
Generally it's nice for libraries to provide Sync futures as it avoids useless errors, but it's also a mistake for any library to require Sync.
Source: https://discord.com/channels/500028886025895936/500336333500448798/1252281055881334784
If you end up with some code that requires the future to be Sync
you can put it inside a sync wrapper
: https://github.com/tokio-rs/tokio/blob/master/tokio/src/util/sync_wrapper.rs
I'd be willing to change the deadpool crate so it returns Sync
futures to satisfy code that uses futures wrong. A change like that must not change the hook and manager API though as I don't want to require those futures to be Sync
.
Unless this becomes a major show stopper somewhere I won't be looking into that though. PRs welcome!
Thanks for all the reference it's super helpful! This issue is caused by me, not another library requiring the trait, so I was able to just remove the Sync trait from that future.
db.get().await;
causes problems with the future resulting in an error. I'm not sure exactly where the issue lies.