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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

improvement: cancel current request in batched functions #5432

Merged
merged 3 commits into from Oct 2, 2023

Conversation

kasiaMarek
Copy link
Contributor

No description provided.

@kasiaMarek kasiaMarek changed the title improvement: cancel current request in batched functions [skip ci] improvement: cancel current request in batched functions Jul 13, 2023
@kasiaMarek kasiaMarek force-pushed the batch-function-cancel branch 4 times, most recently from ce3c761 to bc0c04a Compare July 18, 2023 13:00
}
.distinct
.foreach { conn =>
conn.cancelCompilations()
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this was done on purpose since the cancelation was not properly propagated before

if (!queue.isEmpty) {
runAcquire()
}
}
private def runAcquire(): Unit = {
if (!isPaused.get() && lock.compareAndSet(false, true)) {
runRelease()
val id = rand.nextInt()
Copy link
Contributor

Choose a reason for hiding this comment

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

Random could be zero,no? This should probably be a raising number. Why do we need the additional int though?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Before cancel() would clear the queue and do unlock(). But we still may get a response from the request that was currently processed, which would also do ulock() as callback. We are loosing control over the lock a bit. Not sure if that is a real problem though. Now when we also do cancel on the currently processed request, we have no guarantee the futures underneath will actually react to cancel, so I'm making sure that only the non-cancelled currently processed request will have onComplete executed. There is most probably a better way to do this.

@kasiaMarek kasiaMarek force-pushed the batch-function-cancel branch 2 times, most recently from 40c1b48 to 4679686 Compare July 24, 2023 14:41
@kasiaMarek kasiaMarek marked this pull request as ready for review August 25, 2023 09:28
Copy link
Contributor

@tgodzik tgodzik left a comment

Choose a reason for hiding this comment

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

Thanks for working on this! I think this is almost ready, though I have doubts if the tests wouldn't cause us any flakiness

)
.zip {
// wait until the compilation start
Thread.sleep(1000)
Copy link
Contributor

Choose a reason for hiding this comment

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

Could this have a potential to be flaky? A compilation might take less than that, no? You could try some macros that do Thread.sleep to make sure

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed

Copy link
Contributor

@tgodzik tgodzik left a comment

Choose a reason for hiding this comment

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

LGTM! Could you just rebase on main?

@kasiaMarek kasiaMarek merged commit 60a1d16 into scalameta:main Oct 2, 2023
22 of 24 checks passed
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.

None yet

2 participants