On 2009-11-23 at 18:24:48 [+0100], Alexandre Deckner <alex@xxxxxxxxxxxx> wrote: > Ingo Weinhold wrote: > > > > On a 32 bit machine watching a node (not watched by anyone else) costs 72 > > bytes of kernel heap. There's a minimal CPU overhead for checking whether > > an > > event for a watched node occurred and some overhead for actually sending a > > node monitoring message. Watching a directory's contents is just watching > > a > > single node for a specific event. > > > > > > The mechanism requires a kernel resource (kernel heap), so a soft limit is > > in order to protect the system. > > > > > > Ok, thanks. So the next question is, does a query already node monitors > it's results (internally) to generate the query update events? Not like that. A live query is "registered" with the underlying file system, which is responsible for sending out the query events (via notify_query_entry_{created,removed}) when necessary. How it does the respective bookkeeping is completely up to the implementation. The automatic node monitoring subscription Axel suggested could probably be added in the notify_query_entry_*() functions or further downstream (haven't had a closer look yet). > Wouldn't > adding another type of event (like B_ENTRY_MOVED) for queries make sense? That could be done, yes. A notify_query_entry_moved() would need to be added and all file systems supporting live queries would need to be adjusted to call it. CU, Ingo