std::task - Revamp TaskBuilder API #14989
Conversation
|
@huonw Thanks for the numerous good suggestions (which github seems to've dropped completely after a force-push? I thought it kept the old comments around... Am I doing something wrong here??) I've implemented nearly all of your suggestions, with two exceptions:
|
Oh oops, my fault. I must've commented on the commit directly, not the PR-wide "files changed" view (I try to avoid doing that for exactly this reason). Commit comments are dropped with a force push, but comments on that view just become "outdated ...". You can get the old comments if you have the old hash of that commit (via Those two exceptions sound fine to me. |
| }); | ||
| assert_eq!(res.ok().unwrap(), "Success!".to_string()); | ||
| pool.shutdown(); | ||
| } |
There was a problem hiding this comment.
This is so slick, I wonder if the SchedPool api should be scaled back...
This patch consolidates and cleans up the task spawning APIs: * Removes the problematic `future_result` method from `std::task::TaskBuilder`, and adds a `try_future` that both spawns the task and returns a future representing its eventual result (or failure). * Removes the public `opts` field from `TaskBuilder`, instead adding appropriate builder methods to configure the task. * Adds extension traits to libgreen and libnative that add methods to `TaskBuilder` for spawning the task as a green or native thread. Previously, there was no way to benefit from the `TaskBuilder` functionality and also set the scheduler to spawn within. With this change, all task spawning scenarios are supported through the `TaskBuilder` interface. Closes rust-lang#3725. [breaking-change]
This commit brings code downstream of libstd up to date with the new TaskBuilder API.
|
@alexcrichton I've addressed all of your comments. |
|
This looks great. @aturon do you have confidence that |
|
@brson Yes, I plan on improving That effort is separate from the post 1.0 goal of a comprehensive async IO API, which might also involve a futures-like construct (but likely as a separate and more general notion of "Event"). |
…anic, r=Veykril fix: derive source scope from syntax node to be transformed Fixes rust-lang#14534 When we use `PathTransform` for associated items of a trait, we have been feeding `SemanticsScope` for the trait definition to it as source scope. `PathTransform` uses the source scope to resolve paths in associated items to find which path to transform. In the course of path resolution, the scope is responsible for lowering `ast::MacroType`s (because they can be written within a path) using `AstIdMap` for the scope's `HirFileId`. The problem here is that when an associated item is generated by a macro, the scope for the trait is different from the scope for that associated item. The former can only resolve the top-level macros within the trait definition but not the macro calls generated by those top-level macros. We need the latter to resolve such nested macros. This PR makes sure that we pass `SemanticsScope` for each associated item we're applying path transformation to.
…anic, r=lnicola minor: remove commented out conflicts Follow-up to rust-lang#14989 🤦♂️
This patch consolidates and cleans up the task spawning APIs:
future_resultmethod fromstd::task::TaskBuilder,and adds a
try_futurethat both spawns the task and returns a futurerepresenting its eventual result (or failure).
optsfield fromTaskBuilder, instead adding appropriatebuilder methods to configure the task.
TaskBuilderfor spawning the task as a green or native thread.Previously, there was no way to benefit from the
TaskBuilderfunctionality andalso set the scheduler to spawn within.
With this change, all task spawning scenarios are supported through the
TaskBuilderinterface.Closes #3725.
[breaking-change]