aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>2022-04-27 12:21:25 +0000
committerGitHub <[email protected]>2022-04-27 12:21:25 +0000
commit9c283cd44504d6d9d6f9e352e4c7a8d043bd673f (patch)
treeacd5a0bf15ece515c576673cfcfd8a81bd8d91f9 /docs
parentdf814f9bbd5cc03f4d60eb8cb19374d23f0a84a0 (diff)
parent1599009a4f5fe1a0f9596b7b27bfd9fd84366377 (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