1. 27 Jan, 2015 2 commits
  2. 21 Jan, 2015 1 commit
  3. 16 Jan, 2015 24 commits
    • Allison Karlitskaya's avatar
      kqueue backend: port to new GLocalFileMonitor API · 862580f0
      Allison Karlitskaya authored
      This is the bare minimal effort.  This seems not to crash immediately,
      but it definitely needs some better testing.
      
      The backend is not in good shape.  It could use some serious work.
      862580f0
    • Allison Karlitskaya's avatar
      GPollFileMonitor: use thread default main context · 0ebbf60b
      Allison Karlitskaya authored
      Attach the GPollFileMonitor to the thread default main context instead
      of the global default.
      
      This matches the behaviour of the other file monitors.
      0ebbf60b
    • Allison Karlitskaya's avatar
      inotify: simplify "boredom" algorithm · bf5b55bf
      Allison Karlitskaya authored
      The rules are now very simple: if we wake up and it's not interesting
      then we sleep for a given amount of time (100ms) before checking again.
      
      Also: introduce a smarter mechanism for getting all of the events
      currently in the buffer.
      bf5b55bf
    • Allison Karlitskaya's avatar
      inotify: implement the "boredom" algorithm · 54ca2ad9
      Allison Karlitskaya authored
      Also: add a hashtable for move pairing
      54ca2ad9
    • Allison Karlitskaya's avatar
      inotify: plumb "interesting" through · 272c3fc7
      Allison Karlitskaya authored
      272c3fc7
    • Allison Karlitskaya's avatar
      GFileMonitorSource: return "interesting" value · 8220d6ce
      Allison Karlitskaya authored
      Return an "interesting" boolean from the event handler function on
      GFileMonitorSource.
      
      An event was "interesting" if it will result in a signal actually being
      dispatched to the user.  It is "uninteresting" if it only hit an
      already-dirty rate limiter.
      
      We will use this information to do some backing off in the backends when
      faced with a flood of uninteresting events.
      8220d6ce
    • Allison Karlitskaya's avatar
      GFileMonitor: send final CHANGED on CHANGES_DONE · 5f28cb4b
      Allison Karlitskaya authored
      CHANGES_DONE would delete the pending change record, ignoring the dirty
      flag.  That means that a rate-limited CHANGED event would effectively be
      dropped.  Fix up that inconsistency by reporting the CHANGED before the
      CHANGES_DONE if the dirty bit was set.
      5f28cb4b
    • Allison Karlitskaya's avatar
      GFileMonitor: get rid of APPEARED events · 9b49073f
      Allison Karlitskaya authored
      We could accomplish what we want by simply reporting CREATED directly
      followed by CHANGES_DONE.
      
      We may want to add back _APPEARED some day and allow people to opt into
      it separately via a GFileMonitorFlag if they really care about the
      distinction.  It would certainly be nicer to allow the backends to
      report this case with a distinct event type and have GFileMonitorSource
      do the right thing.
      9b49073f
    • Allison Karlitskaya's avatar
      GFileMonitor: add APPEARED event · 9620e043
      Allison Karlitskaya authored
      ...and try to send it for some common cases in inotify.
      
      We're now abusing the WATCH_MOVES flag as a general "opt-in to new API".
      That's bad.
      9620e043
    • Chun-wei Fan's avatar
      giomodule.c: Include Some Forgotten Headers · a3bfeef2
      Chun-wei Fan authored and Allison Karlitskaya's avatar Allison Karlitskaya committed
      The headers are used for G_TYPE_INITABLE and
      G_NETWORK_MONITOR_EXTENSION_POINT_NAME, which led to undefined variables
      if not included...
      a3bfeef2
    • Allison Karlitskaya's avatar
      start on 'gio' tool · f90709ea
      Allison Karlitskaya authored
      f90709ea
    • Allison Karlitskaya's avatar
      substantially rework file monitors · 9a7838db
      Allison Karlitskaya authored
      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.
      
      Add a couple of extra utility functions to GLocalFile so that we can
      skip some memory copies (and skip the gvfs detection logic when choosing
      which backend to use).  Expose the pre-existing "is_remote"
      functionality.
      
      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.
      
      This mega-commit is a work in progress -- it should probably be broken
      up.
      9a7838db
    • Allison Karlitskaya's avatar
      inotify: rewrite inotify-kernel · 00b245d7
      Allison Karlitskaya authored
      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
      00b245d7
    • Allison Karlitskaya's avatar
      Make GContextSpecificSource internally "public" · c534be15
      Allison Karlitskaya authored
      Expose GContextSpecificSource so that things in GIO can use it directly.
      
      Add support for a user_data area in the struct which will be helpful for
      some intended use cases.
      
      Also expose a way to emit a signal directly on a single source without
      having to go through the group.
      c534be15
    • Allison Karlitskaya's avatar
      GContextSpecificGroup: support for complex signals · 34680b75
      Allison Karlitskaya authored
      Add support for non-VOID__VOID signals to GContextSpecificGroup.
      
      We keep the VOID__VOID case as a special optimised case by usual the
      usual bit-stealing tricks.
      34680b75
    • Allison Karlitskaya's avatar
      Make GUnixMountMonitor per-context · 43f525f5
      Allison Karlitskaya authored
      GUnixMountMonitor was not threadsafe before.  It was a global singleton
      which emitted signals in the first thread that happened to construct it.
      
      Move it to a per-context singleton model where each GMainContext gets
      its own GUnixMountMonitor.  Monitor for the changes from the GLib worker
      thread and dispatch the results to each context with an active monitor.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=742599
      43f525f5
    • Allison Karlitskaya's avatar
      gunixmounts: move GUnixMountMonitor code · ba0a3c81
      Allison Karlitskaya authored
      Move this code to the correct part of the file.
      
      While we're at it, drop an unused #define MOUNT_POLL_INTERVAL.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=742599
      ba0a3c81
    • Allison Karlitskaya's avatar
      gunixmounts.c: add fold markers · 01836de0
      Allison Karlitskaya authored
      This is a large file with a lot of very complicated code in it.  Add
      some fold markers to make things a bit more manageable.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=742599
      01836de0
    • Allison Karlitskaya's avatar
      Deprecate g_unix_mount_monitor_set_rate_limit() · e5424fa1
      Allison Karlitskaya authored
      Deprecate g_unix_mount_monitor_set_rate_limit() and turn it into a
      no-op.
      
      This function doesn't behave as advertised.  It only controls rate
      limiting for filesystem-based monitors.  It has no impact over reporting
      mount changes on Linux, for example, because those are based on polling
      for changes in /proc (which doesn't use filesystem monitors).  It also
      has no impact on Mac OS because a library interface is used there.
      
      This was added in https://bugzilla.gnome.org/show_bug.cgi?id=521946 in
      order to be used by HAL, which is effectively dead.  udisks no longer
      uses this code at all.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=742599
      e5424fa1
    • Allison Karlitskaya's avatar
      Rename g_unix_mount_monitor_new() to _get() · 265c1660
      Allison Karlitskaya authored
      This is a singleton, but we have a function called _new() to get it.
      What's worse is that the documentation makes no mention of this, and
      actually specifically says that a new monitor will be created each time.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=742599
      265c1660
    • Allison Karlitskaya's avatar
    • Allison Karlitskaya's avatar
      Add internal helper GContextSpecificGroup · 23bd6d30
      Allison Karlitskaya authored
      Add a new internal helper called GContextSpecificGroup.
      
      This is a mechanism for helping to maintain a group of context-specific
      monitor objects (eg: GAppInfoMonitor, GUnixMountMonitor).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=742599
      23bd6d30
    • Allison Karlitskaya's avatar
      Add g_main_context_ensure_is_owner() · 795d1deb
      Allison Karlitskaya authored
      This new function is intended to be used for verifying that operations
      on objects that belong to a given main context are only made from valid
      places.
      
      The usual rule is that the operations must be performed while the main
      context is acquired, but an exception is made for the global default
      main context so that things can be set up before running the main loop.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=742599
      795d1deb
    • Allison Karlitskaya's avatar
      GThread: add internal "debug name" helper · 94599349
      Allison Karlitskaya authored
      Add an internal function to get the name of a thread for display in
      debugging messages.  We support reporting "the main thread" for the
      thread that our ctor got run in (which is almost definitely what most
      people would consider to be 'the main thread').
      
      https://bugzilla.gnome.org/show_bug.cgi?id=742599
      94599349
  4. 15 Jan, 2015 1 commit
  5. 14 Jan, 2015 4 commits
  6. 13 Jan, 2015 2 commits
  7. 10 Jan, 2015 1 commit
    • Allison Karlitskaya's avatar
      configure.ac: reject 'universal' builds · 84a1efea
      Allison Karlitskaya authored
      AC_C_BIGENDIAN can return 'universal' as the result in the case that we
      are trying to do a universal build on Mac OS.  This has to be opted into
      explicitly by using multiple -arch CFLAGS.
      
      Previously, we detected this result and fell back to doing our own check
      based on the endianness of the build machine, hardcoding that.  This
      means that universal builds might successfully build, but the binaries
      would never actually run correctly on the 'opposite' arch.
      
      This check was added because of a bug in the intial implementation of
      this detection in autoconf, which was inappropriately identifying
      non-macos compilers as 'universal'.  That was hitting ppc64 systems.
      See https://bugzilla.redhat.com/show_bug.cgi?id=449944 for more info.
      
      Commit b0e687ef42e21b1eb7af18c4eaebcd41b0bd5632 in autoconf ("Limit
      AC_C_BIGENDIAN univeral checks to Mac OS X") solved this issue in 2008,
      so let's remove our workaround.  For good measure, if we detect
      "universal" in the result, error out.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=742548
      84a1efea
  8. 09 Jan, 2015 1 commit
  9. 07 Jan, 2015 1 commit
    • Chun-wei Fan's avatar
      Win32: Update Pre-configured Config Headers · 1632d571
      Chun-wei Fan authored
      Update config.h.win32.in and glibconfig.h.win32.in so that they will be
      in-line with the ones that are produced with configure.ac, for use on
      Windows builds.
      
      Thanks to Philip Withnall for pointing out the changes needed to update
      glibconfig.h.win32.in in bug 727829.
      1632d571
  10. 05 Jan, 2015 2 commits
  11. 24 Dec, 2014 1 commit