diff options
| author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2022-04-27 12:21:25 +0000 |
|---|---|---|
| committer | GitHub <[email protected]> | 2022-04-27 12:21:25 +0000 |
| commit | 9c283cd44504d6d9d6f9e352e4c7a8d043bd673f (patch) | |
| tree | acd5a0bf15ece515c576673cfcfd8a81bd8d91f9 /docs | |
| parent | df814f9bbd5cc03f4d60eb8cb19374d23f0a84a0 (diff) | |
| parent | 1599009a4f5fe1a0f9596b7b27bfd9fd84366377 (diff) | |
Merge #736
736: executor: allow Send-spawning of tasks if their args are Send. r=Dirbaio a=Dirbaio
This allows send-spawning (spawning into an executor in another thread) tasks if their args are Send. Previously this would require the entire future to be Send.
--
When send-spawning a task, we construct the future in this thread, and effectively
"send" it to the executor thread by enqueuing it in its queue. Therefore, in theory,
send-spawning should require the future `F` to be `Send`.
The problem is this is more restrictive than needed. Once the future is executing,
it is never sent to another thread. It is only sent when spawning. It should be
enough for the task's arguments to be Send. (and in practice it's super easy to
accidentally make your futures !Send, for example by holding an `Rc` or a `&RefCell` across an `.await`.)
Luckily, an `async fn` future contains just the args when freshly constructed. So, if the
args are Send, it's OK to send a !Send future, as long as we do it before first polling it.
Co-authored-by: Dario Nieuwenhuis <[email protected]>
Diffstat (limited to 'docs')
0 files changed, 0 insertions, 0 deletions
