Audit I/O code for failure-safety #8674
Labels
A-runtime
Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
Comments
bors
added a commit
that referenced
this issue
Aug 25, 2013
Also added a home_for_io_with_sched variant to consolidate some cases. This is a temporary step to resolving #8674.
bors
added a commit
that referenced
this issue
Nov 25, 2013
The reasons for doing this are: * The model on which linked failure is based is inherently complex * The implementation is also very complex, and there are few remaining who fully understand the implementation * There are existing race conditions in the core context switching function of the scheduler, and possibly others. * It's unclear whether this model of linked failure maps well to a 1:1 threading model Linked failure is often a desired aspect of tasks, but we would like to take a much more conservative approach in re-implementing linked failure if at all. Closes #8674 Closes #8318 Closes #8863
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Jul 18, 2022
…ait_bound, r=flip1995 Add `repeated_where_clause_or_trait_bound` lint I thought I would try and scratch my own itch for rust-lang#8674. 1. Is comparing the `Res` the correct way for ensuring we have the same trait? 2. Is there a way to get the spans for the bounds and clauses for suggestions? I tried to use `GenericParam::bounds_span_for_suggestions` but it only gave me an empty span at the end of the spans. I tried `WhereClause::span_for_predicates_or_empty_place` and it included the comma. 3. Is there a simpler way to get the trait names? I have used the spans of the traits because I didn't see a way to get it off the `Res` or `Def`. changelog: Add ``[`repeated_where_clause_or_trait_bound`]`` lint.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Code that interacts with the scheduler is wildly unsafe and probably not being properly defensive about recovering from failure or at least
rtabortingon unexpected failure.In particular, in the current iteration, I/O blocking is subject to linked task failure, under which blocked tasks my resume and fail, and this is not recovered correctly. In the short term we should make all I/O blocking non-interruptable, then handle interruptability on a case-by-case basis.
The text was updated successfully, but these errors were encountered: