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).
Add a new GFileMonitorFlag: G_FILE_MONITOR_WATCH_HARD_LINKS. When set,
changes made to the file via another hard link will be detected.
Implement the new flag for the inotify backend.
https://bugzilla.gnome.org/show_bug.cgi?id=532815
This adds support for G_FILE_MONITOR_SEND_MOVED events when requested by
the user to the inotify backend. Last part to fix bug #547890.
Based heavily on a patch by Martyn Russel <martyn@lanedo.com>.
2007-11-26 Alexander Larsson <alexl@redhat.com>
* Makefile.am:
* configure.in:
* gio-2.0-uninstalled.pc.in:
* gio-2.0.pc.in:
* gio-unix-2.0-uninstalled.pc.in:
* gio-unix-2.0.pc.in:
* gio/
* docs/reference/gio
Merged gio-standalone into glib.
* glib/glibintl.h:
* glib/gutils.c:
Export glib_gettext so that gio can use it
Add P_ (using same domain for now)
Add I_ as g_intern_static_string
svn path=/trunk/; revision=5941
