[gamin] Re: [PATCH] inotify 0.5

[John McCutchan <ttb tentacle dhs org>]

On Tue, 2004-07-27 at 06:05, Daniel Veillard wrote:
>   Sorry for the delay, my laptop decided to break while at OLS making
> mail and related work near impossible...
> 

No problem.

> On Wed, Jul 21, 2004 at 10:47:10PM -0400, John McCutchan wrote:
> [...]
> > My idea is that when we are packaging the events for the client we can
> > scan the events we have already queued to be sent to the client, and if
> > the events are the same we toss the one out. A couple questions.. (I
> > haven't gotten a firm grasp on FAM/gamin yet) does the client (aka
> > nautilus,etc) ask for all pending events ? or do we just push them down
> > a fd and nautilus reads them whenever it feels like it?
> 
>   it's synchronous, the second kind, which makes filtering a bit harder.
> The main problem  people raised (with fam) is that if a file is being
> monitored (or in a monitored dir) and grows very fast, you get a continuous
> stream of FAM event consuming most of your CPU. Avoiding this effect
> could be done by rate limiting Changed events for a given file. You still
> don't want to block them completely as FAM is used for example to monitor
> log files.
> 
> > Either way I think flow control and event merging shouldn't be too hard.
> > We just need a staging ground for 'new events' where we could batch them
> > up and say once per second send them off to the clients or fd.
> 
>   yup, you don't want to delay the event, but block successive Changed events
> until a given delay. This can be done completely server based.

I am working on this right now. For each connection I have added a queue
of changes, and then when an event comes down that is already in the
queue I just toss it out (What about reqno's?). After a set delay the
queue gets flushed and all events get sent down the fd. How does this
sound?

> 
> > > > One question about gamin, why does it not have a backend shutdown
> > > > routine? 
> > > 
> > >   I'm not 100% sure I understand, maybe the answer is because
> > > this wasn't available in the FAM API.
> > 
> > We should be able to add this right? It shouldn't affect the fam API,
> > just when gamin is shutting down call a backend shutdown callback.
> 
>   I'm still unclear. Do you mean libgamin ? How would the library knows
> it's shutting down, since FAM is the only user visible interface from the
> library to the application (and I would really like to keep it that way).
> It seems I'm missing something, or do you mean a internal API call at the
> server level when it's shutting down (say on SIGINT signal) ?

Sorry, I meant in the server. I have been reading more of the gamin
code, and I realize now that it should be fine to add a shutdown
callback for the backend.

I have a couple questions for you though,

1) What is this request number all about?
2) Why do we send EXIST events? This doesn't really mesh well with
inotify since you can't watch anything in inotify until it exists.
3) When I am using the dnotify backend and I create a file in a
directory being watched I get 2 Create events one with just the filename
and the second with the full path name. Is this a bug or what?
4) What is gamin supposed to mean?

Thanks,

John