Hey Prakash, 2 comments see below:
prakash sangappa wrote: PS> [snip] PS> PS> We have a good discussion going. To summarize... PS> PS> PS> File event types PS> PS> FILE_ACCESS File was accessed PS> FILE_MODIFIED File was modified. PS> FILE_CREATE File/directory was created. PS> FILE_DELETE File/directory was deleted. PS> FILE_ATTRIB File/directory attribute changed PS> FILE_OPEN File was opened. PS> FILE_CLOSE_WRITE File that was modified got closed. PS> FILE_CLOSE_NOWRITE File was closed without modification. PS> FILE_RENAME_FROM File was renamed from this name. PS> FILE_RENAME_TO File was renamed to this name. PS> PS> PS> Exception events: PS> PS> UNMOUNTED Watched filesystem got umounted. PS> DELETED File that was being watched got deleted. PS> OVERFLOW Events queue is full. PS> PS> PS> Additional directives, PS> NOTIFY_ONCE De-register after the first event PS> delivery. PS... PS> Proposal was to report multiple events as on event, like signals, PS> till it PS> is read(no queuing). Also, the file events can be watched on a file or a PS> directory. To be more precise: multiple events of the same kind as one event (but clearly to differentiate between different file events delivered as different "notifications" - or - to distinguish between different files being e.g. opened as separate events). So e.g., a change of the same file multiple times would result in generating an additional "event" each time the file is e.g. changed. If the "consumer" (aka application) has not "processed" the event - fine . The "bit" mask for exactly that "event" would be set to "1" each time the file is changed. ((Needless to say, that event ports guarantees no race conditions here ... )) When another file that is "monitored" is changed, it would result in another event (clearly). So this is still true: PS> Each event can provide additional PS> details other then the event, ex file name when a file is created If we go for this (which has its nice sides, too, I agree), than we don't need the above: PS> There appears to be a need for queuing events. ... We PS> could possible PS> provide this with some limit set on the queue size. This will address PS> issues with PS> events being generated at a faster rate then they can be read, call it PS> queuing issue. PS> Once the number of events queued exceed the limit, an OVERFLOW event is PS> sent to indicate PS> that. The subsequent events will be dropped by the system. Once the PS> application PS> receives an OVERFLOW event it can perform necessary action to find out PS> what has changed. Best regards, Michael -- Michael Schulte [EMAIL PROTECTED] OpenSolaris Kernel Development http://opensolaris.org/ _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
