-
Notifications
You must be signed in to change notification settings - Fork 3
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
Switch to using DispatchWorkItem for cancelation #24
base: master
Are you sure you want to change the base?
Conversation
… there was a small queue-order issue that was making tests accidentally succeed)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m not going to act like I fully understand all the nuances of what’s going on in this code, but it looks good me to me 🤷♂️.
DispatchQueue.main.asyncAfter(deadline: DispatchTime.now() + 0.1) { | ||
token.cancel() | ||
} | ||
self.wait(for: [expectation], timeout: 0.5) | ||
} | ||
|
||
func testCancelPromiseAfterFulfilment() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing an L in fulfillment :)
self.onCancel = wrappedBlock | ||
} | ||
if let workItem = workItem { | ||
let cancelItem = DispatchWorkItem(block: onCancel) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to use enforceQoS: DispatchWorkItemFlags it should increase priority for cancelation tasks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
inheritQoS would be better don't you think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as far as I understand these very similar flags they increase priority for tasks:
static let enforceQoS: DispatchWorkItemFlags
//Prefer the quality-of-service class associated with the block.
static let inheritQoS: DispatchWorkItemFlags
//Prefer the quality-of-service class associated with the current execution context.
Here we work with blocks then we should use enforceQoS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nah, it shouldn't raise the priority of the queue and indirectly other tasks? if its inherit, then its own qos can be raised to a higher one if the queue specifies it. But otherwise no.
} | ||
|
||
case .promise(let promise): | ||
if self.cancelFlag.isCanceled { | ||
if self.isCanceled { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you need self
?
@benski @chow-land @mvyrko just like old times 👍 |
The implementation of
AtomicCancel
could not be verified by static or runtime analysis. As an alternative, I've switched the underlying implementation to use DispatchWorkItem.All the tests pass fine, and I added some short dispatch_after delays to make sure that the tests weren't false positives.
In the future, I might be able to replace more code paths with
DispatchWorkItem
.