[bug#33265] [WIP RFC v4] services: Add file system monitoring service.

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]