Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revisit linked failure mechanism #1868

Closed
brson opened this issue Feb 19, 2012 · 9 comments
Closed

Revisit linked failure mechanism #1868

brson opened this issue Feb 19, 2012 · 9 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
Milestone

Comments

@brson
Copy link
Contributor

brson commented Feb 19, 2012

Our mechanism for propagating failure between tasks is not fully realized, has race conditions, and imposes complex interactions between the runtime and libcore.

The current rules are something like this:

  • Children that fail cause their parents to fail
  • Parents that fail do not cause their children to fail
  • Children can be 'unsupervised', after which their failure does not propagate to their parents
  • Children of dead parents that fail cause their grandparents (and so on) to fail
  • The main task is supervised by the kernel
  • When the kernel fails all tasks are killed

Issues:

  • Parents should probably also cause children to fail
  • Task notification (by which tasks can be informed of what the fate of other tasks was) is related, but the current semantics are not clear when linked failure is involved.
  • There is a known race condition between children killing their parents and the parent blocking on a port in which it is possible for the parent to yield forever.
  • Kernel level failure, upon which all tasks fail, is incredibly racy, basically broken.

See also: #1788 (redesign task API), #1857 (task-local data), #1078 (task notification)

@brson
Copy link
Contributor Author

brson commented Feb 19, 2012

Also #1189 (move linked failure into library)

@brson
Copy link
Contributor Author

brson commented Feb 19, 2012

My primary goals are a) to move complexity out of the runtime, b) use the standard comm API for implementing linked failure, c) eliminate the special rules around kernel failure, d) make task notification work correctly with linked failure

@brson
Copy link
Contributor Author

brson commented Feb 19, 2012

#1789 is also related but probably impossible to solve to any degree if linked failure is moved into the library.

@ghost ghost assigned brson Apr 5, 2012
@brson
Copy link
Contributor Author

brson commented May 8, 2012

Not happening for 0.3

@bblum
Copy link
Contributor

bblum commented Jul 18, 2012

I think we should settle for failure-vs-notification races being nondeterministic. I don't think any meaningful solution exists that covers general cases.

@bblum
Copy link
Contributor

bblum commented Jul 19, 2012

Hmm. With the way I've currently got it, it's nondeterministic whether the grandchild here will get killed:

do task::spawn_unlinked_parented() {
    do task::spawn_unlinked_parented() {
        loop { task::yield(); }
    }
}
fail;

Is this desirable? My instinct says no, but it's slightly harder to implement..! (requires each task have a list of ancestor parent task-groups that might kill it; also O(n) space and time in the number of generations)

(cc @graydon)

@bblum
Copy link
Contributor

bblum commented Jul 20, 2012

@brson
Copy link
Contributor Author

brson commented Aug 2, 2012

I gave it a close read and am very happy with how this works now. Great work.

@bblum
Copy link
Contributor

bblum commented Aug 2, 2012

Thanks so much! :)

@brson brson unassigned bblum Jun 16, 2014
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Kobzol pushed a commit to Kobzol/rust that referenced this issue Dec 30, 2024
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
bors pushed a commit to rust-lang-ci/rust that referenced this issue Jan 2, 2025
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
Projects
None yet
Development

No branches or pull requests

2 participants