Hi Ludo, On Sun, 11 Nov 2018 12:25:45 +0100 ludo@gnu.org (Ludovic Courtès) wrote: > > registered - see the "/does_not_exist" workaround) rapid fswatch invocations > > would waste (potentially enormous amounts of) cpu time and would > > forkbomb fswatch, shepherd and/or worse things. On the other hand, using > > fswatch like we do now causes us to lose events. But so does starting fswatch > > later than the clients. And most fswatch backends (for example the Linux one) > > can lose events anyway (since the kernel buffer is limited - Linux will then > > drop events). That's why it always calls the handlers when restarting - just > > in case. > > Uh, not very confidence-inspiring. ;-) Yeah well, file change notification is surprisingly crappy - especially when you want it to *always* work. On the other hand typical UNIX :) > OK that works, but I’m not very comfortable with the approach: normally > respawns indicate that the service failed unexpectedly, so here we’re > really abusing the mechanism IMO. I agree. In the end it would be nicer to get the pipe thing to work or better yet to have libfswatch bindings or better yet use direvent, aha. > Another option would be to use Direvent, which supports this and more, Aha, that looks as if it's intended exactly for this use case! Nice! I'll try that one next. > or maybe ‘inotifywatch’ from inotify-tools though it seems to be quite > similar to fswatch feature-wise. inotifywatch is Linux-specific. If we want Guix to support the Hurd, BSD, Windows then it shouldn't be using Linux-specific things. Also, it uses the same stuff as fswatch under the hood so it has the same limitations.