3 ms·
It increases the places it can be used, but it decreases what type can be returned. Not all types can be sent between threads (in particular, types that feature
by dureuill 3y ago
It increases the places it can be used, but it decreases what type can be returned. Not all types can be sent between threads (in particular, types that feature unsynchronized mutability through shared references are not Send). If you executor is local to one thread, it can be a blocker if a trait you use suddenly requires your future to be Send.
- andy_xor_andrew 3y agoah, ok. so this is for scenarios where you, the library author, define the trait, and users will implement it. But since different users have different requirements, you provide two+ trait definitions, so they can pick if they need Send or not.
- Arnavion 3y agoYes. Say the HttpService trait comes from some third-party library. I implement that trait on my server, and then I run my server on a single-threaded executor. (This is analogous to how Iterator is in libstd but I can implement it on my own type and then use that Iterator with a for-loop / combinator in my own code.) My implementation returns Futures that are not Send and my executor does not need them to be Send, so it would be wasteful if the trait required the Futures to be Send.