| |||||||||||||
inotify?inotify?Posted Sep 3, 2008 2:40 UTC (Wed) by liamh (subscriber, #4872)In reply to: inotify? by dlang Parent article: TALPA strides forward
OK. Then wouldn't it make sense to make this effort be an inotify next generation (robust and scalable) project, thereby avoiding the issue of the eventual application(s)? I use inotify now for something which has nothing to do with virus scanning, and I can imagine other applications as well, so perhaps there is a need for this anyway, quite apart from the scanners. It seems like a bad idea to have two independent partially overlapping subsystems in the kernel.
Liam
(Log in to post comments)
inotify? Posted Sep 3, 2008 8:21 UTC (Wed) by njs (guest, #40338) [Link]
There's been talk of such things (OS X has a similar scalable mixed kernel/user-space notification service that it uses for things like indexing), and it absolutely should be created for Linux -- but TALPA has requirements well beyond that. Blocking read(2) until some other userspace process has woken up and okay'ed things is *way* outside the scope of an inotify-alike!
inotify? Posted Sep 3, 2008 18:51 UTC (Wed) by jlokier (guest, #52227) [Link]
Actually it's not so far away from inotify.
We have leases in fcntl() F_SETLEASE, they go alongside dnotify in fcntl() F_NOTIFY.
inotify could similarly benefit from an an ilease extension, as well as further scalability improvements. (inotify was designed to improve on dnotify in many ways including scalability; it's a shame it stopped half way).
That's blocking readers right there.
|
|||||||||||||