In my testing on a work project, I found that unfortunately try_join! will block on the execution of the first future. join! does work perfectly, executing both futures concurrently.
This is reproducible by creating two async functions with blocking operations in each that return Result types. Using try_join! will never complete if the first blocks indefinitely, and the second future will not be run concurrently.
None of the internal concurrency primitives provided in futures will handle blocking futures correctly (which is basically everything outside of futures::executor). I'm not sure why you're seeing join! work, it should function identically to try_join! in this case, they both poll in order in the current implementation so will both stop if the first future blocks.
It might be a good idea to add a crate-level documentation section explaining that blocking will mess with internal concurrency, and link to it from relevant places (all the join and select macros/functions, Futures{Un,}Ordered, etc.)
Most helpful comment
None of the internal concurrency primitives provided in
futureswill handle blocking futures correctly (which is basically everything outside offutures::executor). I'm not sure why you're seeingjoin!work, it should function identically totry_join!in this case, they both poll in order in the current implementation so will both stop if the first future blocks.It might be a good idea to add a crate-level documentation section explaining that blocking will mess with internal concurrency, and link to it from relevant places (all the
joinandselectmacros/functions,Futures{Un,}Ordered, etc.)