Move task notification out of the runtime #1078
Comments
|
Actually, this doesn't depend on #908. Since task failure is catastrophic on Windows, it doesn't matter that we don't send the message during unwinding. |
|
I am doing this via a resource and the code should be pushed soon. |
ghost
assigned
|
turns out that this exposes a bug in the memory management around resources. I will commit an xfail-test shortly that reproduces the problem. |
|
I am not sure if this is possible, actually. The problem is with task supervision: the correct behavior, from my point of view, is that you do not receive a "parent completed" notification until all supervised children have completed. This is because the parent may fail due to a supervised child having failed. If we put the notification message into a resource, it will fire a "succeeded!" msg as soon as the parent's task completes, but it may be that some child has not yet completed so the parent may later actually be killed. Therefore I am going to close the issue. |
|
Oof, good point. Surely there will (someday) be a viable way to do this in rust-land. Maybe by just joining on all children. Seems like we might be able to combine this with the (buggy) linked failure mechanism. |
|
OK, well actually, until this very moment I had always considered a parent that exited normally to be a success, even if the child later fails (the child will still manage to fail the grandparent, the scheduler etc., skipping the dead parent). But your description sounds more sane. |
|
I still have a desire to make this work. I'm going to reopen unless you're strongly opposed. |
|
No, not strongly opposed. |
|
(also d9e8efc) |
Merge some lints together This PR merges following lints: - `block_in_if_condition_expr` and `block_in_if_condition_stmt` → `blocks_in_if_conditions` - `option_map_unwrap_or`, `option_map_unwrap_or_else` and `result_map_unwrap_or_else` → `map_unwrap` - `option_unwrap_used` and `result_unwrap_used` → `unwrap_used` - `option_expect_used` and `result_expect_used` → `expect_used` - `wrong_pub_self_convention` into `wrong_self_convention` - `for_loop_over_option` and `for_loop_over_result` → `for_loops_over_fallibles` Lints that have already been merged since the issue was created: - [x] `new_without_default` and `new_without_default_derive` → `new_without_default` Need more discussion: - `string_add` and `string_add_assign`: do we agree to merge them or not? Is there something more to do? → **not merge finally** - `identity_op` and `modulo_one` → `useless_arithmetic`: seems outdated, since `modulo_arithmetic` has been created. fixes rust-lang#1078 changelog: Merging some lints together: - `block_in_if_condition_expr` and `block_in_if_condition_stmt` → `blocks_in_if_conditions` - `option_map_unwrap_or`, `option_map_unwrap_or_else` and `result_map_unwrap_or_else` → `map_unwrap_or` - `option_unwrap_used` and `result_unwrap_used` → `unwrap_used` - `option_expect_used` and `result_expect_used` → `expect_used` - `for_loop_over_option` and `for_loop_over_result` → `for_loops_over_fallibles`
…p-filling Remove clone() when removing extra stack operations
This adds instructions for sqrt and some of the missing reciprocal square-root estimate instructions.
Co-authored-by: Adrian Palacios <73246657+adpaco-aws@users.noreply.github.com>
To enable joining with tasks, they have a 'notification' feature where the task will send a message when it exits, regardless of success or failure. This currently involves a lot of work in the runtime, but with unwinding can all be done in Rust. Depends on #908.
The text was updated successfully, but these errors were encountered: