Introduce an alternative Linux implementation using inotify…#7
Introduce an alternative Linux implementation using inotify…#7savetheclocktower wants to merge 1 commit into
inotify…#7Conversation
…that fits our feature set better than EFSW’s does and doesn’t have the complexity of recursive watching.
|
Tentatively good news — one user affected by pulsar-edit/pulsar#1592 says that this fixes it for them. So after this lands, I'll be motivated to write a Windows-specific adapter as well so that we can finally retire EFSW. I'm grateful for EFSW’s existence (I tried rewriting |
|
Paging @Daeraxa as an “unofficial” reviewer. (We should get you added to the appropriate list so you can do real reviews!) |
I will be happy to review as soon as I can, sorry I've been absurdly busy recently and won't be able to look properly until Monday, but I will look! |
…that fits our feature set better than EFSW’s does and doesn’t have the complexity of recursive watching.
In pulsar-edit/pulsar#1592 we're dealing with a crash whose origin seems to be a memory allocation issue somewhere within
pathwatcher— specifically EFSW’sinotifyimplementation. We could chase it down further, but we'd basically be debugging vendor code at that point, and I'd much rather dedicate the same level of effort toward a replacement.A while back, when EFSW’s macOS implementation didn't fit our needs, I wrote an API-compatible
FSEventsadapter that we could use in its place. (Then, much more recently, whenFSEventsseemed to mean regressions in certain cases, I wrote a separatekqueue-based adapter to use instead.)This PR extends this idea further by adding a new
inotify-based adapter for Linux that can be used instead of EFSW'sinotifyimplementation. Our adapter has the advantage of being much simpler becausepathwatcherdoesn't do recursive filesystem watching; it cares only about directories and their direct children.I cannot promise that this itself will prevent the crashes reported in pulsar-edit/pulsar#1592, but it should at the very least move them toward code that we maintain and can understand much better.
The tests pass on my Linux VM; if they pass in CI, I'll make a draft PR in the Pulsar repo that points to this
pathwatcherbranch simply for the purpose of generating binaries that affected users can download to see whether this fixes the issue.