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).
Remove all event merging and dispatch logic from GFileMonitor. The only
implementation of GFileMonitor outside of glib is in gvfs and it already
does these things properly.
Get rid of GLocalDirectoryMonitor. We will use a single class,
GLocalFileMonitor, for both directory and file monitoring. This will
prevent every single backend from having to create two objects
separately (eg: ginotifydirectorymonitor.c and ginotifyfilemonitor.c).
Introduce GFileMonitorSource as a thread-safe cross-context dispatch
mechanism. Put it in GLocalFileMonitor. All backends will be expected
to dispatch via the source and not touch the GFileMonitor object at all
from the worker thread.
Remove all construct properties from GLocalFileMonitor and remove the
"context" construct property from GFileMonitor. All backends must now
get the information about what file to monitor from the ->start() call
which is mandatory to implement.
Remove the implementation of rate limiting in GFileMonitor and add an
implementation in GLocalFileMonitor. gvfs never did anything with this
anyway, but if it wanted to, it would have to implement it for itself.
This was done in order to get the rate_limit field into the
GFileMonitorSource so that it could be safely accessed from the worker
thread.
Expose g_local_file_is_remote() internally for NFS detection.
With the "is_remote" functionality exposed, we can now move all
functions for creating local file monitors to a proper location in
glocalfilemonitor.c
Port the inotify backend to adjust to the changes above. None of the
other backends are ported yet. Those will come in future commits.
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>.
2008-01-21 Alexander Larsson <alexl@redhat.com>
* inotify/Makefile.am:
* inotify/inotify-helper.c:
* inotify/inotify-kernel.c:
* inotify/inotify-path.c:
* inotify/local_inotify.h: Removed.
* inotify/local_inotify_syscalls.h: Removed.
Removed the included copies of the inotify
headers. We now only use the <sys/inotify.h>
header which exists on modern systems.
This fixes problems on ARM and SH5 (#510448)
but is also generally much cleaner and future
safe. For instance, if other OSes add support
for inotify it should "just work".
svn path=/trunk/; revision=6338
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
