mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2024-11-10 19:36:18 +01:00
c5d5e2916b
Use the "interesting" value from g_file_monitor_source_handle_event() to decide if we're currently being flooded by a stream of boring events. The main case here is when one or more files is being written to and the change events are all being rate-limited in the GFileMonitor frontends. In that case, we become "bored" with the event stream and add a backoff timeout. In the case that it is exactly one large file being written (which is the common case) then leaving the event in the queue also lets the kernel perform merging on it, so when we wake up, we will only see the one event. Even in the case that the kernel is unable to perform merging, the context switch overhead will be vastly reduced. In testing, this cuts down on the number of wake ups during a large file copy, by a couple orders of magnitude (ie: less than 1% of the number of wake ups). |
||
|---|---|---|
| .. | ||
| ginotifydirectorymonitor.c | ||
| ginotifydirectorymonitor.h | ||
| ginotifyfilemonitor.c | ||
| ginotifyfilemonitor.h | ||
| inotify-helper.c | ||
| inotify-helper.h | ||
| inotify-kernel.c | ||
| inotify-kernel.h | ||
| inotify-missing.c | ||
| inotify-missing.h | ||
| inotify-path.c | ||
| inotify-path.h | ||
| inotify-sub.c | ||
| inotify-sub.h | ||
| Makefile.am | ||