Use kqueue backend on BSDs
ryanavella opened this issue · 3 comments
Apologies for the necro in the older issue, I genuinely thought my symptoms were identical. I hope opening a new issue is appropriate, but if not please gently guide me in the right direction.
I am running FreeBSD 14.0 and I find that the watch feature doesn't pick up immediately on changes, sometimes taking 30+ seconds or (rarely) hanging indefinitely.
The root problem appears to be that cargo-watch pulls in watchexec 1.17.2, which in turn pulls in notify 4.0.18 which relied on a polling backend on BSDs. notify does have support for a kqueue backend as of 5.0.0-pre.11, and the most straightforward way I can see to get this backend into cargo-watch would be to upgrade the watchexec dependency to (at minimum) 2.0.0-pre.0.
I've forked and spent a few hours attempted to upgrade watchexec to 2.0.0-pre.0, and understandably it is a difficult refactor, mostly due to the API having changed significantly between watchexec 1.17.2 and watchexec 2.0.0-pre.0, especially in regards to handlers and configuration. I think I first need to familiarize myself with both versions of watchexec and the organization of cargo-watch before I could even think of pulling off a refactor, but if you have any suggestions that would be greatly appreciated.
I maintain and develop both. Watchexec post 1.17 has issues with filtering that I believe would lead to a slew of complaints from cargo-watch use, even if they have workarounds; after many iterations over the past few years I aim to definitely fix these sometime in the next six months, then port cargo-watch over.
I would consider a ''beta'' cargo-watch port to the current version of the watchexec lib if so contributed, but won't do that myself before the above timeline to avoid burnout.
If you do attempt: do not upgrade to 2.0.0-pre.N. Go for the current release. The pre releases were all unstable and changed wildly before 2.0.0; there's zero advantage to using those.
Alternatively you could try to retrofit a newer notify into watchexec 1.17; I'd accept a PR for that over there and make a patch release (possibly gated behind a feature to obey semver) so it can then be pulled into current cargo watch.