Added event filter for emitters#989
Conversation
|
Thanks a lot @marioga, that's perfect! |
|
I hoped to use this feature before realising it was so recently added, so I'm looking forward to this getting into a stable release. One observation is that there's a comment in
However, I can't see any evidence of that here, so unless I'm mistaken it looks like if someone sets an event filter without directory events then the recursive mode will be broken. Perhaps either this documentation should be amended, or the directory events implicitly added for the inotify case if running in recursive mode? |
In this PR, we add the capability of filtering which events are fired at the emitter level before inserting them to the event queue. In the case of inotify events, we optimize one step further and mask out events we are not interested in when we call
inotify_add_watch. We tried to keep the API as general as possible and the changes are fully backwards compatible.I noticed that there's an earlier draft PR that tried to achieve something similar here: https://github.com/gorakhargosh/watchdog/pull/911/files. It appears to be incomplete and largely abandoned though, so I figured I'll attempt my own thing.
The motivation for this work is that we observed a performance hit in some of our projects when upgrading to the latest watchdog. Events like file opening/closing can be very spammy, especially in a recursive setting. We successfully use the code in this PR to only fire events we care for in our project, e.g., file modifications.