Commit Graph

24 Commits

Author SHA1 Message Date
Emmanuel Fleury
3b02d4641e Fix missing initializer warning in gio/inotify/inotify-kernel.c:ik_source_new()
gio/inotify/inotify-kernel.c: In function ‘ik_source_new’:
gio/inotify/inotify-kernel.c:377:3: error: missing initializer for field ‘finalize’ of ‘GSourceFuncs’ {aka ‘struct _GSourceFuncs’}
  377 |   };
      |   ^
In file included from glib/giochannel.h:33,
                 from glib/glib.h:54,
                 from gio/inotify/inotify-kernel.c:30:
glib/gmain.h:272:14: note: ‘finalize’ declared here
  272 |   void     (*finalize) (GSource    *source); /* Can be NULL */
      |              ^~~~~~~~
2020-12-16 23:26:34 +01:00
Дилян Палаузов
512655aa12 minor typos in the documentation (a/an) 2019-08-24 19:14:05 +00:00
Maya Rashish
de2ad60578 Include <sys/filio.h> for FIONREAD 2019-06-04 13:13:37 +03:00
Philip Withnall
5cddde1fb2 Consistently save errno immediately after the operation setting it
Prevent the situation where errno is set by function A, then function B
is called (which is typically _(), but could be anything else) and it
overwrites errno, then errno is checked by the caller.

errno is a horrific API, and we need to be careful to save its value as
soon as a function call (which might set it) returns. i.e. Follow the
pattern:
  int errsv, ret;
  ret = some_call_which_might_set_errno ();
  errsv = errno;

  if (ret < 0)
    puts (strerror (errsv));

This patch implements that pattern throughout GLib. There might be a few
places in the test code which still use errno directly. They should be
ported as necessary. It doesn’t modify all the call sites like this:
  if (some_call_which_might_set_errno () && errno == ESOMETHING)
since the refactoring involved is probably more harmful than beneficial
there. It does, however, refactor other call sites regardless of whether
they were originally buggy.

https://bugzilla.gnome.org/show_bug.cgi?id=785577
2017-08-03 10:21:13 +01:00
Sébastien Wilmet
6000f25e4f gio/inotify/: LGPLv2+ -> LGPLv2.1+
https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-29 19:53:34 +02:00
Sébastien Wilmet
f60590534d License headers: "the Gnome Library" -> "this library"
Harmonize a little the license headers. In most of the license headers
in GLib, it is "this library".

It is also what is explained at:
https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html#SEC4
"How to Apply These Terms to Your New Libraries"

https://bugzilla.gnome.org/show_bug.cgi?id=776586
2017-01-04 19:12:56 +01:00
Ryan Lortie
fd40b5942d inotify: fix move event matching accounting
The hash table stores the list of unmatched IN_MOVE_FROM events, but we
were removing entries from it when popping IN_MOVE_TO events.

Fix that up to correct a crash in nautilus due to the assertion failure
below.

https://bugzilla.gnome.org/show_bug.cgi?id=746749
2015-03-26 14:56:25 -04:00
Ryan Lortie
c5d5e2916b inotify: implement "boredom" algorithm
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).
2015-03-20 12:01:35 -04:00
Ryan Lortie
2737ab3201 substantially rework file monitors
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.
2015-03-20 11:59:47 -04:00
Ryan Lortie
779c809a3d inotify: rewrite inotify-kernel
Remove the hardwired 1 second event queue logic from inotify-kernel and
replace it with something vastly less complicated.

Events are now reported as soon as is possible instead of after a
delay.

We still must delay IN_MOVED_FROM events in order to look for the
matching IN_MOVED_TO events, and since we want to report events in order
this means that events behind those events can also be delayed.  We
limit ourselves, however:

 - no more than 100 events can be delayed at a time

 - no event can be delayed by more than 10ms

https://bugzilla.gnome.org/show_bug.cgi?id=627285
2015-03-20 11:58:42 -04:00
Ryan Lortie
450e7b1036 configure.ac: tweak inotify check
Our check for inotify_init1() being defined is broken.  We happily
declare that inotify is supported, even if the check fails.

This was originally intended to check for inotify_init1 in the libc so
that we could fall back to inotify_init if it was not yet defined.

FreeBSD has a libinotify that emulates the inotify API via kqueue.  It
installs a <sys/inotify.h> header and requires linking to -linotify.  We
don't want to falsely detect working inotify in this case.

Treat the lack of inotify_init1() in the libc as a lack of inotify
support.  This requires only a new libc -- we still support old kernels:
in the case that inotify1_init() fails, we fall back to inotify_init().

https://bugzilla.gnome.org/show_bug.cgi?id=724330
2014-02-14 10:42:40 -05:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Matthias Clasen
3bdd8a2c88 Use GLIB_PRIVATE_CALL macro
I accidentally pushed the fix for bug 704873 before
applying this cleanup.
2013-07-28 18:44:41 -04:00
Ryan Lortie
abbb225738 inotify: don't assume mainloop is running
GFileMonitor takes great care to sample the thread-default main context
at the time that it is created in order that events can be dispatched to
the correct thread when they come in.

The inotify GFileMonitor implementation uses a global file descriptor
shared between all watches.  It has to poll this file descriptor from
somewhere so it arbitrarily picks the default main context.

The problem with that is that the user might not be running it.

Let's use the GLib worker thread for this instead.  It's guaranteed to
be running if you need it, and this is exactly the sort of problem it
was meant to solve.

https://bugzilla.gnome.org/show_bug.cgi?id=704873
2013-07-28 17:19:38 -04:00
Matthias Clasen
e546eb016a Remove some unused inotify code 2013-06-02 20:01:56 -04:00
Cosimo Alfarano
fd1e9938b3 Send CHANGES_DONE_HINT on file moves if no IN_CLOSE_WRITE is emitted
This patch makes GFileMonitor to emit EVENT_CHANGES_DONE_HINT when
EVENT_CREATED is emitted but the file is not opened for writing.

On file moves across different mounted volumes, inotify will always emit
IN_CREATE and IN_CLOSE_WRITE (plus other events).
This translates into GIO's _EVENT_CREATED and _EVENT_CHANGES_DONE_HINT.

On file moves across the same mounted volumes, inotify will emit
IN_MOVED_FROM/IN_MOVED_TO which will be translated into
_EVENT_DELETED/_EVENT_CREATED GIO's side. No _EVENT_CHANGES_DONE_HINT is
emited afterwards.
Under such circumstances a file indexer does not know when actually the
file is ready to be indexed, either waiting too much or triggering the
indexing twice. On small devices it's not advisable.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=640077
Bug-NB: NB#219982
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Tomas Bzatek <tbzatek@redhat.com>
2011-12-05 18:27:34 +00:00
Matthias Clasen
c003468296 Correct a comment 2010-08-13 17:23:44 -04:00
Colin Walters
d2fe46b476 Annotate all custom GIO GSource using g_source_set_name
Naming the sources allows easier debugging with e.g. SystemTap
probes.

https://bugzilla.gnome.org/show_bug.cgi?id=620536
2010-07-10 20:09:34 -04:00
Christian Kellner
48f74cab39 Move event support in the inotify backend
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>.
2010-02-18 15:50:26 +01:00
Josselin Mouette
cc4970cf94 Fall back to inotify_init if inotify_init1 does not work
This fixes monitoring failing to work when glib is built on a 2.6.27+
kernel but run on an older one.

http://bugs.debian.org/544354
https://bugzilla.gnome.org/show_bug.cgi?id=593775
2009-09-23 18:39:45 +02:00
Matthias Clasen
8a3a3d797e Use inotify_init1 when available
To avoid leaking the inotify fd. Fixes bug 585478.
2009-06-14 22:29:17 -04:00
Alexander Larsson
d8473705b0 Removed. Removed. Removed the included copies of the inotify headers. We
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
2008-01-21 10:35:44 +00:00
Matthias Clasen
a043325ec1 Coding style fixes
svn path=/trunk/; revision=6337
2008-01-21 05:12:16 +00:00
Alexander Larsson
3781343738 gio/ docs/reference/gio Merged gio-standalone into glib.
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
2007-11-26 16:13:05 +00:00