Nicolas Dumazet <nicdumz.commits@gmail.com> [Fri, 22 May 2009 10:26:56 +0900] rev 8606
inotify: use a decorator instead of dispatching calls
Nicolas Dumazet <nicdumz.commits@gmail.com> [Fri, 22 May 2009 09:57:53 +0900] rev 8605
inotify: do not defer inotify events processing
Doing a part of the event processing and deferring the rest is a bad
habit: it complexifies the code, and it does not respect event ordering!
Moreover, there is already a timeout handling, so that inotify events are
only processed when a treshold is exceeded: there is no requirement to
delay anymore the events processing.
Nicolas Dumazet <nicdumz.commits@gmail.com> [Thu, 21 May 2009 15:55:58 +0900] rev 8604
inotify: do not recurse in handle_timeout(): call it explicitely, not in scan()
When in handle_timeout, scan() is called when a repertory is created/modified.
But the first line of scan calls handle_timeout.
This had the consequence of calling recursively handle_timeout:
* several calls to read_events (but only the first one retrieves events)
* every time that an event is queued for a deferred action, the next time that
scan() is called, handle_timeout is called, the event queue is treated,
even if all the events haven't been read/queued yet. This could lead to
inconsistencies