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

middleware.refresh: elide a lock for the "refresh-clear" op #873

Merged
merged 1 commit into from
May 5, 2024

Conversation

vemv
Copy link
Member

@vemv vemv commented May 5, 2024

@vemv vemv merged commit 458efba into master May 5, 2024
35 of 55 checks passed
@vemv vemv deleted the cider--3652 branch May 5, 2024 20:22
@@ -76,12 +76,18 @@
msg]
(reload-utils/after-reply error msg))

(def ^{:added "0.48.0"} user-indicated-clear?
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this name is good, as it's too specific and it's possible that some op might be triggered in a different way as opposed to a direct request from an IDE. (unlikely, but possible) Should this be named just reset-in-progress or something like this?

(locking refresh-tracker
(vreset! refresh-tracker (track/tracker))))
;; This used to be a `locking`-based call to our `clear` implementation
;; Now it merely "enqueues" a clearing, because the "refresh-clear" op is called synchronously by CIDER,
Copy link
Member

Choose a reason for hiding this comment

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

It's best to avoid CIDER specifics here, as the middleware aims to be client-neutral outside of Emacs-specific features like Eldoc.

@vemv
Copy link
Member Author

vemv commented May 5, 2024

Thanks! Will re-visit tomorrow.

@vemv vemv mentioned this pull request May 7, 2024
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.

refresh ops shouldn't have a timeout
2 participants