config option for KDirWatch method

[Josef Spillner]

On Wednesday 22 August 2007 11:11:47 Josef Spillner wrote:
> That's probably the most stupid API design I've seen for a while,
> because you effectively have to access() every file beforehand.

Forget that part please. But using ENOSPC hidden in errno is not much 
better :_/

Anyway, here's the updated tool which supports recursive scanning so everybody 
can test out limits. On my system, the 8k watch limit is hit immediately 
(within a second or so). Even if recursive watches will not make it into the 
kernel anytime soon, we might still want to ask about raising this limit 
significantly. Adding watches in the background with a low priority will not 
slow down the system by much.

As for dropping large amounts of files somewhere, I also think that this can 
be solved with a batch approach in strigi. After all, this is what both 
inotify and epoll try to advocate: The caller determines the buffer size and 
thus determines how many events in parallel can be handled. In the worst 
case, for each file a file name and inotify struct would have to be kept in 
memory, but the watch limit would kick in before this reaches a noticeable 
size. Strigi should still set a limit on its own to deal with future watch 
limit relaxations.

Josef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inotifydir.c
Type: text/x-csrc
Size: 3365 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070822/1035129a/attachment.c>