Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[RFC] Refactor cancellation for great justice #910
I was continuing my effort to shoehorn linked cancel scopes and graceful cancellation into
Current core cancel logic expressed in the new system:
I think the extension to support a grace period would just be:
Maybe that's not quite simple but it is miles better than what I was looking at before. :-)
Some more thoughts on this after sleeping on it:
then the shield means the cancellation gets caught by
As usual for my first comment on these large diffs, I have spent a bunch of time thinking about the high-level idea but haven't actually read the diff, so apologies if anything I say is way off.
It took me a while to wrap my head around it, but I think the basic idea of having separate objects that track the aggregate cancel status for each extent is pretty good. But, I think it's probably simpler and more performant to keep deadlines separate from the cancel status. So what I'm imagining is something like:
There are two reasons I like this overall approach:
What do you think of this, at a high level?
A few more thoughts:
Here's an idea for managing deadline entries in the global table: we only put
I hope at this point you've heard enough of my design philosophy that you won't be too surprised when I say this sounds like a negative to me, not a positive :-). (But whatever, we don't have to expose it even if it is nice and clean.)
Many thanks for the detailed feedback!
That was exactly what I was hoping for in this case - the code is still pretty hacked together at this point. The system you've detailed is uncannily close to the one I was imagining / tried to implement, and many of the differences (especially wrt tracking cancelled-ness explicitly as opposed to well-I-guess-this-deadline-is-in-the-past-ly) are changes I was planning to make as well. (Your
I think tracking graceful cancellation will require more state than this. For example:
So far I've been imagining each cancel status tracking a tuple (effective deadline, effective cleanup deadline), and the type of cancel status inserted by
Apart from that detail I really like this approach, and I agree with you about the simplicity of reasoning and the algorithmic probably-ideality.
This is the same thing we're doing for
I suspected you would say that, but I had to try :P. I'm fine not exposing the flexibility; I think even having the internal architecture be flexible will make it a lot easier to prototype improvements to the cancellation system in the future.
Well, this is borrowing trouble, since we don't know if we'll implement soft cancels yet :-). But my intuition would be: if we do, then we extend
Yeah, I guess I just thought of it because with the PR's approach, using the deadline itself to track cancellation, then you sort of automagically get the deadline/cancel-status in sync all the time, so I was wondering if there was any way to keep that on the outside while using simpler state tracking internally.
Yeah, for sure.