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

Switch to using DispatchWorkItem for cancelation #24

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

benski
Copy link
Owner

@benski benski commented Apr 11, 2020

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.

Copy link

@jake-iheart jake-iheart left a 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() {

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)
Copy link
Collaborator

@mvyrko mvyrko Apr 12, 2020

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.

Copy link
Contributor

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

Copy link
Collaborator

@mvyrko mvyrko Apr 13, 2020

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.

Copy link
Contributor

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 {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you need self?

@ralph-e-boy
Copy link
Contributor

@benski @chow-land @mvyrko just like old times 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants