gamin 0.1.7

[Jean-Yves Lefort]

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

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

No, let's continue using mine.

> > I don't want to use their poller.
> 
> And then why you want to use gamin? Create a fork. They generalized the 
> polling system so that every backend can use it in a consistent way. 
> Inotify and dnotify already use it. And in any case you can override the 
> 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.
> 
> I may agree, but the 0.1.5 version was doing it? No, so this is a 
> desiderable enhancement, not a reason to rollback.
> 
> > 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.
> 
> I don't know what was doing before, but I didn't touch that part of code 
> and it's exactly identical to 0.1.5. Tests work. Again, this is not a 
> 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.
> 
> And this is what is done even on 0.1.7. Look at the code, the cleanup 
> step is always called.

killall -9 gam_server

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

-- 
Jean-Yves Lefort

jylefort at FreeBSD.org
http://lefort.be.eu.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20060209/46a85ca3/attachment.bin