Dirty files

[Milian Wolff]

On Monday 17 May 2010 22:16:04 Aleix Pol wrote:
> On Mon, May 17, 2010 at 9:56 PM, Esben Mose Hansen <kde at mosehansen.dk>wrote:
> > On Sunday 16 May 2010 22:37:39 Andreas Pakulat wrote:
> > > Sure, but one needs to know the limits too. Unfortunately KDirWatch is
> > > not well documented wrt. its limits.
> > 
> > If KDirWatch uses inotify (which is likely), then the limit is 8192 on my
> > machine to be exact. From reading the code, there seems to be no other
> > limits.
> > That would almost be a problem for kdebase, with 4000+ cpp+h files and
> > possibly that many generated files of assorted kinds. However, inotify
> > can be
> > set to watch the directories that the files reside in instead,
> > drastically reducing the need for watchers, at the price of getting some
> > events we are not
> > interested in.
> > 
> > I can find no limits for the less like case of using libfam/famd.
> > 
> > --
> > Kind regards, Esben
> > 
> > --
> > KDevelop-devel mailing list
> > KDevelop-devel at kdevelop.org
> > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
> 
> So who should track these changes?
> - language support? (here there's no file structure whatsoever)
> - project support? (there are involved files for which the parser doesn't
> know anything)
> 
> Here I guess the proper thing to do would be to let the language support to
> watch each included directory and just check the dirty directories
> recursively, that might make kdevelop a little slow while system upgrades
> but other than that I can't see any stopper.

If at all, only the included files in the active document should be checked. I 
doubt these go into the thousands. Or use some kind of timer, like we do 
currently after the document got changed. This one should just have a higher 
timeout of 1sec or something.

If the document gets switched, KDevelop checks for updates in the included 
files anyways. Hence nothing needs to be done there.
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100517/f21f13b8/attachment.sig>