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 _______________________________________________ Gamin-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gamin-list
