fs: Pre-filter the event kind before acquiring global lock and cloning callback handlers (#55683) (cherry-pick to stable) - #55942
Merged
Conversation
…g callback handlers (#55683) In #54481, the `handle_event` function was altered to check for an `Access` event after the callbacks were acquired via a global state lock. The lock/Vec-collect has enough overhead (or maybe there's enough lock contention?) that the handler isn't performant enough to keep up with the volume of inotify events, and its queue fills up, resulting in [a rescan event getting emitted](https://github.com/notify-rs/notify/blob/79007aefb41d9f853d00656eb768600e3ea41ee0/notify/src/inotify.rs#L304-L306), which presumably results in *more* access events for the file as it's rescanned, which further serve to fill up the inotify queue. Moving the check for an `Access` event and returning before doing anything remotely expensive seems to resolve the issues I've been having lately. Not sure if it addresses the original issue in #53480 though. Longer-term, it might be prudent to do the event handler's heavy-lifting in a separate thread with its own event queue, and let the handler passed to the `notify` crate be just a dumb `tx` sender. Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content is consistent with the [UI/UX checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Related to #53480 Fixes #55829 Release Notes: - Fixed inotify event queue overflows on linux
cla-bot
Bot
added
the
cla-signed
Anthony-Eid
approved these changes
May 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cherry-pick of #55683 to stable
In #54481, the
handle_eventfunction was altered to check for anAccessevent after the callbacks were acquired via a global statelock. The lock/Vec-collect has enough overhead (or maybe there's enough
lock contention?) that the handler isn't performant enough to keep up
with the volume of inotify events, and its queue fills up, resulting in
a rescan event getting
emitted,
which presumably results in more access events for the file as it's
rescanned, which further serve to fill up the inotify queue.
Moving the check for an
Accessevent and returning before doinganything remotely expensive seems to resolve the issues I've been having
lately. Not sure if it addresses the original issue in #53480 though.
Longer-term, it might be prudent to do the event handler's heavy-lifting
in a separate thread with its own event queue, and let the handler
passed to the
notifycrate be just a dumbtxsender.Self-Review Checklist:
checklist
Related to #53480
Fixes #55829
Release Notes: