Date: Thu, 9 Feb 2006 16:26:33 +0100 From: Jean-Yves Lefort <jylefort@FreeBSD.org> To: Alex Dupre <ale@FreeBSD.org> Cc: ports@FreeBSD.org, marcus@FreeBSD.org Subject: Re: gamin 0.1.7 Message-ID: <20060209162633.0624d302.jylefort@FreeBSD.org> In-Reply-To: <43EB5511.7070705@FreeBSD.org> References: <43EB5511.7070705@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Signature=_Thu__9_Feb_2006_16_26_33_+0100_0H3aIwomSDwknJc+ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 09 Feb 2006 15:43:29 +0100 Alex Dupre <ale@FreeBSD.org> wrote: > > Please address the following issues, or revert: > >=20 > > - we now have two different pollers; one is used when > > gam_kqueue_monitor_enable_kqueue() returns FALSE (for instance when > > the fd limit is exhausted, or when kevent() fails); one is used for > > "nfs" and "smbfs" filesystems >=20 > Yes, and where is the problem? Not only for nfs and smbfs, but also for=20 > all the filesystem the user want to monitor using polling, by inserting=20 > them into the configuration file. Before, this wasn't possible. The=20 > internal polling of kqueue backend will be used only for files that=20 > could be monitored by the kernel, but actually exceeds the fd limit (and= =20 > so they could return to kernel later). The problem is that the two pollers behave differently. > > - the two pollers behave differently, compare: stat() vs lstat(), > > gam_poll_generic_node_changed() vs gam_kqueue_differs(), >=20 > Yes, this is true. For POLA may be better to adapt the polling behaviour= =20 > to be like the kqueue backend, even if other gamin backend are different. I don't want to use their poller. If you want to force polling for remote filesystems, you must do it in gam_kqueue_monitor_enable_kqueue() (return FALSE and the kqueue poller will be used). > > - using filesystem names to choose between kqueue and polling is a > > bad idea, for obvious reasons; >=20 > This is what is done partially in FAM and other gamin backends. > > > one should use fstatfs() and enable kqueue if the MNT_LOCAL flag is set >=20 > Before, all the file systems where monitored by kqueue, so I don't see=20 > your point. My point is that it's better to ask the system if a filesystem is remote rather than hardwiring a few known remote filesystem names. > > - testing no longer works: > > make > > cd $WRKDIR/tests > > export GAMIN_DEBUG_SERVER=3D../server/gam_server > > ./testgam - > > connect test > > -> it connects to the already running gam_server (the installed one) >=20 > If you have an already running gam_server it's absolutely right that the= =20 > libgamin will connect to it. Your env variable is used only when forking= =20 > a new server. Before it forked the executable specified in GAMIN_DEBUG_SERVER rather than using the already running gam_server, so I could test the backend without disrupting my GNOME session. I want that behaviour to be restored. > > - the patch which removed a stale socket has been dropped >=20 > False, the patch has changed, not dropped. The bind() call in gam_listen_unix_socket() fails if the file already exists. My patch addressed that issued by unlinking the already existing file. --=20 Jean-Yves Lefort jylefort@FreeBSD.org http://lefort.be.eu.org/ --Signature=_Thu__9_Feb_2006_16_26_33_+0100_0H3aIwomSDwknJc+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD618pyzD7UaO4AGoRAqdHAJ9MKXVpELtVtQIjsWfwvkPtk8M9LQCfYC/V 7Iqsmy8Va/O9/2ljfY5uwJk= =dqCf -----END PGP SIGNATURE----- --Signature=_Thu__9_Feb_2006_16_26_33_+0100_0H3aIwomSDwknJc+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060209162633.0624d302.jylefort>