From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLotM-0003Zk-DN for guix-patches@gnu.org; Sun, 11 Nov 2018 07:31:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLotL-0007kJ-Gr for guix-patches@gnu.org; Sun, 11 Nov 2018 07:31:04 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:41111) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gLotK-0007je-PM for guix-patches@gnu.org; Sun, 11 Nov 2018 07:31:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gLotK-0003bL-IF for guix-patches@gnu.org; Sun, 11 Nov 2018 07:31:02 -0500 Subject: [bug#33265] [WIP RFC v4] services: Add file system monitoring service. Resent-Message-ID: Date: Sun, 11 Nov 2018 13:30:52 +0100 From: Danny Milosavljevic Message-ID: <20181111133052.4c4dfbe4@scratchpost.org> In-Reply-To: <87wopjua86.fsf@gnu.org> References: <20181105035122.4359-1-dannym@scratchpost.org> <20181105094109.21915-1-dannym@scratchpost.org> <87a7mgwp6e.fsf@gnu.org> <20181111011218.00265d2f@scratchpost.org> <87wopjua86.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/RtPw24zf5Tk_XV7vchc5CgP"; protocol="application/pgp-signature" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 33265@debbugs.gnu.org --Sig_/RtPw24zf5Tk_XV7vchc5CgP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo, On Sun, 11 Nov 2018 12:25:45 +0100 ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > > registered - see the "/does_not_exist" workaround) rapid fswatch invoca= tions > > would waste (potentially enormous amounts of) cpu time and would > > forkbomb fswatch, shepherd and/or worse things. On the other hand, usi= ng > > 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 Lin= ux 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. =20 >=20 > 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=E2=80=99m not very comfortable with the approach: no= rmally > respawns indicate that the service failed unexpectedly, so here we=E2=80= =99re > 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 =E2=80=98inotifywatch=E2=80=99 from inotify-tools though it seem= s 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. --Sig_/RtPw24zf5Tk_XV7vchc5CgP Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlvoIPwACgkQ5xo1VCww uqX9vAf8C5cMYvz7JuLNPZF/0swUq1xgGuoBWdRyXDSreNEZ6elMrndI0D/Dahn0 7uTqZQcgNV25kWJ3fjMMCEFW1/ft66Lo08hACuxqWVPKr8VVM+XTPO4enr+SmYcM WbwXl0CYJYNOe+NZHNJvrvmSZWaXhcEbawL70EPJfPXTJrxRFcrpo8w1qhFjR5Kg bvF+6VTzcsqzkc05zV7XfLHqlOUvaEBhIYT39AbFychwv0yCY5F0BaGBX8JweXo9 cFRSK7xk3wiKpLMPEL0LYsufJBvcEOkEfg072fUZ7emO/GS7bWF+Ap/3hgP8HcLu h1h4gjxbiRi6+7RH5Qx4zkQqd6C3tA== =BGCc -----END PGP SIGNATURE----- --Sig_/RtPw24zf5Tk_XV7vchc5CgP--