Possible deadlocks with overlapping subscriptions

[abrenneke]

This is a followup to #39 and specifically @bpasero's comment and my comment.

I have no definitive proof, but our CLI app (interactive app that runs builds) was occasionally completely freezing. We finally found a reproduction - we had a java folder that wasn't ignored for the parcel watcher, and when we ran a java build concurrently with other CPU work in the CLI app the app would completely freeze (node event loop unresponsive).

The app was organized so that .subscribe was called for the same folder several times, so there were 5 or so watchers on the same folder. After reading the comment above, I refactored the app to reuse a single watcher and a single .subscribe call. I've been unable to reproduce the freeze since then.

Considering that the freeze was

• CPU pressure sensitive, happens more on slower computers
• Reproduced by tons of FS activity in a folder parcel watcher was watching
• "Felt" like a deadlock
• Froze node event loop (sync call of some sort)
• Seems to be gone after refactoring use of parcel watcher
• Couldn't find anything else to explain it after tons of debugging the app (logging async_hooks)
• While debugging, could not reproduce after commenting out all but one watcher

Makes me think there's a deadlock of some sort here. I'm on the latest version 2.1.0.

My questions I suppose are:

1. Is this a bug?
2. Could this happen between two processes? Or is it limited to just 1?
3. Could this happen with any overlapping of folders (e.g. parent and child both subscribed to)? Or only two subscriptions on the same folder?

Thanks for the awesome package though, it's been so much better than every other watcher!

[bpasero]

@devongovett 👋 curious if you could comment on this issue. So far, in VS Code we have actively prevented file system watchers from overlapping, i.e. no watcher was ever watching any folder or sub-folder that was already watched by another watcher in the same process.

However, going forward, I am thinking to relax this condition to enable VS Code extensions to have more powerful file watching capabilities with custom exclude rules, which today is just not possible. My fear is that this could introduce subtle issues that we have not had before if multiple extensions install watchers over same or overlapping paths.

I also noticed the PR to migrate to threadsafe functions (#146), which maybe helps for this issue, if its an issue at all?

@abrenneke have you ever tried to reproduce with newer versions of parcel watcher?