-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Comments
Also #1189 (move linked failure into library) |
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 |
#1789 is also related but probably impossible to solve to any degree if linked failure is moved into the library. |
Not happening for 0.3 |
I think we should settle for failure-vs-notification races being nondeterministic. I don't think any meaningful solution exists that covers general cases. |
Hmm. With the way I've currently got it, it's nondeterministic whether the grandchild here will get killed:
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) |
I gave it a close read and am very happy with how this works now. Great work. |
Thanks so much! :) |
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
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:
Issues:
See also: #1788 (redesign task API), #1857 (task-local data), #1078 (task notification)
The text was updated successfully, but these errors were encountered: