Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 9 Feb 2006 20:21:09 +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:  <20060209202109.41ff6737.jylefort@FreeBSD.org>
In-Reply-To: <43EB88CF.7010308@FreeBSD.org>
References:  <43EB88CF.7010308@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--Signature=_Thu__9_Feb_2006_20_21_09_+0100_lcbCievop91IHrMG
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, 09 Feb 2006 19:24:15 +0100
Alex Dupre <ale@FreeBSD.org> wrote:

> > The problem is that the two pollers behave differently.
>=20
> Let's unify them!

No, let's continue using mine.

> > I don't want to use their poller.
>=20
> And then why you want to use gamin? Create a fork. They generalized the=20
> polling system so that every backend can use it in a consistent way.=20
> Inotify and dnotify already use it. And in any case you can override the=
=20
> default settings in your configuration file.

I don't particularly want to use gamin; I've worked on it because Joe
had already started a kqueue backend, and because I'm more familiar
with GLib than I am with C++ (which FAM is implemented in).

> > 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.
>=20
> I may agree, but the 0.1.5 version was doing it? No, so this is a=20
> desiderable enhancement, not a reason to rollback.
>=20
> > 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.
>=20
> I don't know what was doing before, but I didn't touch that part of code=
=20
> and it's exactly identical to 0.1.5. Tests work. Again, this is not a=20
> reason to rollback.

It was doing what I told you it was doing. And whether it's a reason
to rollback or not we (the devel/gamin maintainers) should decide.

> > 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
> And this is what is done even on 0.1.7. Look at the code, the cleanup=20
> step is always called.

killall -9 gam_server

> To summarize, I don't say my changes are the final solution, as you=20
> noted we can unify the behaviour of polling code and surely add many=20
> other interesting features, but keeping an old static and bugged release=
=20
> it's not better.
> If marcus, as he said, this night will make the basic polling code=20
> coeherent with kqueue (by replacing stat()->lstat() and by adding the=20
> few missing checks on stat fields) I think we'll have a good stable=20
> gamin base on which we could work for enhancements.

I ask him to bypass the linux-centric, questionable vendor poller in
favour of the gam_kqueue.c poller. I can spot several problems with
their poller just by reading the code, and I have no intent to fix
them since my own poller is adequate.

--=20
Jean-Yves Lefort

jylefort@FreeBSD.org
http://lefort.be.eu.org/

--Signature=_Thu__9_Feb_2006_20_21_09_+0100_lcbCievop91IHrMG
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFD65YlyzD7UaO4AGoRAt3OAJwOGp36DA0LT3iLVBP8S0vWtWI/mgCfWCCP
lAmly4aqGvuOwG/CJexCQA4=
=TDT2
-----END PGP SIGNATURE-----

--Signature=_Thu__9_Feb_2006_20_21_09_+0100_lcbCievop91IHrMG--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060209202109.41ff6737.jylefort>