Re: [gamin] gam-poll.c rewrite

["Neal H. Walfield" <neal walfield org>]

At Fri, 1 Jul 2005 08:45:04 -0400,
Daniel Veillard wrote:
>   That is a huge change that I didn't see discussed at all !
> It maybe the right thing but IMHO changes a lot ! For example
> suddenly monitoring a resource may lead to monitoring a very 
> busy directory, or put a monitor onto a kind of filesystem you
> really don't want to match. Trivial example
> 
>    monitor /tmp/app-$user/lock
> 
> which is likely to be done by a number of applications.
> suddently you force to monitor /tmp, which is one of the busiest
> directory on any system. Do that on a machine with 100 users
> and I'm sure to get a flood of bug reports from pissed-off customers
> because there is hundred of gam_servers eating all the CPU on the
> system.

Busy resources automatically go into polling mode.  Is this somehow
insufficient?

> > even though you only need to watch the parent if the
> > directory in question is empty.  However, that is non-trivial and may
> > involve some races (if the last file is unlinked and then the
> > directory as well we might miss the chance to set up the monitor for
> > the parent) so I deferred.
> 
>   If a file or directory is monitored, it gets removed, then I would
> expect a kernel event, then the stat() associated will show the resource
> had disapeared.

dnotify only emits events on directories.  The current approach is to
use dnotify to monitor the parent of a node and scan its contents for
changes.  I think, although I could be wrong, when a directory is
unlinked, its parent gets an event, not it.  Thus the need to monitor a
directory's parent for its removal.

> > Where do you want to go from here?
> 
>   I want to see discussions of features *before* you code them !

To explain my past behavior, I've found that the FLOSS mentality is
generally "show me the code."  Knowing that this is your attitude,
I'll try to have more discussion before I do work.

> You are doing radical design changes, and there is not a single exchange
> of mails about them before hand. You can't work in isolation, I admit
> that the mail-list being down for 2 days (but that was documented/planned)
> doesn't help, but it's a process problem.
> 
>   How to go from there:
>     - I don't think I will accept a patch monitoring all parent directories.
>       That mean we can't even run reliable regression tests anymore, and
>       while I like the work you are doing, being able to make regression
>       tests is even more crucial.

I am confused by your logic: how does not running regressions follow
from monitoring parent directories?  We can still run the regression
tests.

>     - If doing just the parent directory monitoring, then it would be
>       possible to fix the dnotify*.py and flood*.py regression tests

The debugging API exposes implementation details.  If the
implementation changes then of course the debugging events will as
well.  I have listed all the other regressions that I saw in the Gamin
public interface.

>       That's a patch I may accept after checking behaviour on the overall
>       desktop on a couple of OS versions, but that would be a gamin 0.2xx
>       new release, I will not consider this an incremental release of 0.1

Just to make it clear, I have not been pushing for an immediate
release with these changes.

Thanks,
Neal