You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to use join_all to parallelize some async work.
Because my stub function returns a non-Send error type, I consume the error before passing it to join_all using a .map combinator (I have also tried map_err(|e| ())).
The join_all result is then dispatched to tokio:
This fails badly, with rustc trying to teach me type theory:
error: implementation of `std::marker::Send` is not general enough--> src/main.rs:12:5|12 | tokio::run_async(async {| ^^^^^^^^^^^^^^^^|= note: `std::marker::Send`would have to be implemented for the type `std::ptr::Unique<futures_util::future::join_all::ElemState<std::pin::Pin<std::boxed::Box<futures_util::try_future::map_err::MapErr<impl core::future::future::Future, [closure@src/main.rs:14:28: 14:34]>>>>>`, for any lifetime `'0`= note: but `std::marker::Send` is actually implemented for the type `std::ptr::Unique<futures_util::future::join_all::ElemState<std::pin::Pin<std::boxed::Box<futures_util::try_future::map_err::MapErr<impl core::future::future::Future, [closure@src/main.rs:14:28: 14:34]>>>>>`, for some specific lifetime `'1`
However I eventually figured out that if I replace the call to .map(|r| r.is_ok()) by this fut_is_ok wrapper function, everything is fine:
At this point I am already thoroughly confused, but to add to the fun the following things also make the error go away:
Making stub return Result<(), ()> (without removing the map call)
Making stub return a Send error, but only if the map call is removed
Awaiting only one future instead of doing a join_all
I suspect that somewhere deep in its type parameters the combinator version is still somehow keeping track of the non-Send type I'm trying to map away, whereas the free function does not.
Is this error about std::marker::Send expected behavior, and is there some core async/await concept I'm grossly misunderstanding here?
The text was updated successfully, but these errors were encountered:
= note: `std::marker::Send` would have to be implemented for the type `std::ptr::Unique<[futures_util::future::join_all::ElemState<futures_util::future::map::Map<impl core::future::future::Future, fn(std::result::Result<(), std::boxed::Box<(dyn std::error::Error + '0)>>) -> bool>>]>`, for any lifetime `'0`
= note: but `std::marker::Send` is actually implemented for the type `std::ptr::Unique<[futures_util::future::join_all::ElemState<futures_util::future::map::Map<impl core::future::future::Future, fn(std::result::Result<(), std::boxed::Box<(dyn std::error::Error + '1)>>) -> bool>>]>`, for some specific lifetime `'1`
So, the lifetime it is complaining about is the lifetime of the input parameter of the closure. Swapping the closure for an identical actual function compiles fine.
No idea where the actual issue is, but it seems likely to be a bug related to rustc's handling of lifetimes on trait object inputs to closures inside async blocks.
I'm trying to use
join_all
to parallelize some async work.Because my
stub
function returns a non-Send
error type, I consume the error before passing it tojoin_all
using a.map
combinator (I have also triedmap_err(|e| ())
).The
join_all
result is then dispatched to tokio:This fails badly, with rustc trying to teach me type theory:
However I eventually figured out that if I replace the call to
.map(|r| r.is_ok())
by thisfut_is_ok
wrapper function, everything is fine:At this point I am already thoroughly confused, but to add to the fun the following things also make the error go away:
stub
returnResult<(), ()>
(without removing themap
call)stub
return aSend
error, but only if the map call is removedjoin_all
I suspect that somewhere deep in its type parameters the combinator version is still somehow keeping track of the non-
Send
type I'm trying tomap
away, whereas the free function does not.Is this error about
std::marker::Send
expected behavior, and is there some core async/await concept I'm grossly misunderstanding here?The text was updated successfully, but these errors were encountered: