Nicolas Dumazet <nicdumz.commits@gmail.com> [Thu, 21 May 2009 16:54:05 +0900] rev 8607
inotify: handle_event: do not use event and fd parameters.
event is particularly confusing given the context (is it an inotify event?
a polling event?) and is never used. Remove it.
fd has very little use, and it gives the false impression that event handling
depends on fd. It's wrong: the same behavior is triggered, for all events.
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
Henrik Stuart <hg@hstuart.dk> [Sun, 24 May 2009 17:07:27 +0200] rev 8603
i18n-da: typo
Benoit Boissinot <benoit.boissinot@ens-lyon.org> [Sun, 24 May 2009 16:33:22 +0200] rev 8602
merge with crew