gamin 0.1.7

[Jean-Yves Lefort]

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

> > Please address the following issues, or revert:
> > 
> >   - 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
> 
> Yes, and where is the problem? Not only for nfs and smbfs, but also for 
> all the filesystem the user want to monitor using polling, by inserting 
> them into the configuration file. Before, this wasn't possible. The 
> internal polling of kqueue backend will be used only for files that 
> could be monitored by the kernel, but actually exceeds the fd limit (and 
> 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(),
> 
> Yes, this is true. For POLA may be better to adapt the polling behaviour 
> 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;
> 
> 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
> 
> Before, all the file systems where monitored by kqueue, so I don't see 
> 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=../server/gam_server
> > 	./testgam -
> > 	connect test
> > 	-> it connects to the already running gam_server (the installed one)
> 
> If you have an already running gam_server it's absolutely right that the 
> libgamin will connect to it. Your env variable is used only when forking 
> 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
> 
> 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.

-- 
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/d4b07901/attachment.bin