1. 17 Dec, 2020 1 commit
  2. 13 Dec, 2020 1 commit
  3. 12 Dec, 2020 3 commits
  4. 11 Dec, 2020 2 commits
  5. 09 Dec, 2020 6 commits
  6. 29 Nov, 2020 1 commit
  7. 25 Nov, 2020 1 commit
  8. 16 Nov, 2020 1 commit
  9. 03 Nov, 2020 2 commits
    • Emmanuele Bassi's avatar
      Merge branch 'backport-1734-hidden-cache-glib-2-66' into 'glib-2-66' · e18a6a85
      Emmanuele Bassi authored
      Backport !1734 “glocalfileinfo: Use a single timeout source at a time for hidden file cache” to glib-2-66
      See merge request !1736
    • Carlos Garnacho's avatar
      glocalfileinfo: Use a single timeout source at a time for hidden file cache · 92c19ebd
      Carlos Garnacho authored
      As hidden file caches currently work, every look up on a directory caches
      its .hidden file contents, and sets a 5s timeout to prune the directory
      from the cache.
      This creates a problem for usecases like Tracker Miners, which is in the
      business of inspecting as many files as possible from as many directories
      as possible in the shortest time possible. One timeout is created for each
      directory, which possibly means gobbling thousands of entries in the hidden
      file cache. This adds as many GSources to the glib worker thread, with the
      involved CPU overhead in iterating those in its main context.
      To fix this, use a unique timeout that will keep running until the cache
      is empty. This will keep the overhead constant with many files/folders
      being queried.
  10. 28 Oct, 2020 3 commits
    • Simon McVittie's avatar
      Merge branch 'backport-1725-gdbus-fds-glib-2-66' into 'glib-2-66' · 4daaf303
      Simon McVittie authored
      Backport !1725 “gdbus: Cope with sending fds in a message that takes multiple writes” to glib-2-66
      See merge request !1727
    • Simon McVittie's avatar
      gio/tests/gdbus-peer: Exercise fds attached to a large message · 60c3c948
      Simon McVittie authored
      This incidentally also exercises the intended pattern for sending fds in
      a D-Bus message: the fd list is meant to contain exactly those fds that
      are referenced by a handle (type 'h') in the body of the message, with
      numeric handle value n corresponding to g_unix_fd_list_peek_fds(...)[n].
      Being able to send and receive file descriptors that are not referenced by
      a handle (as in OpenFile here) is a quirk of the GDBus API, and while it's
      entirely possible in the wire protocol, other D-Bus implementations like
      libdbus and sd-bus typically don't provide APIs that make this possible.
      Reproduces: #2074
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Simon McVittie's avatar
      gdbus: Cope with sending fds in a message that takes multiple writes · 40cd84d9
      Simon McVittie authored
      Suppose we are sending a 5K message with fds (so data->blob points
      to 5K of data, data->blob_size is 5K, and fd_list is non-null), but
      the kernel is only accepting up to 4K with each sendmsg().
      The first time we get into write_message_continue_writing(),
      data->total_written will be 0. We will try to write the entire message,
      plus the attached file descriptors; or if the stream doesn't support
      fd-passing (not a socket), we need to fail with
      "Tried sending a file descriptor on unsupported stream".
      Because the kernel didn't accept the entire message, we come back in.
      This time, we won't enter the Unix-specific block that involves sending
      fds, because now data->total_written is 4K, and it would be wrong to try
      to attach the same fds again. However, we also need to avoid failing
      with "Tried sending a file descriptor on unsupported stream" in this
      case. We just want to write out the data of the rest of the message,
      starting from (blob + total_written) (in this exaple, the last 1K).
      Resolves: #2074
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
  11. 27 Oct, 2020 2 commits
    • Emmanuele Bassi's avatar
      Merge branch 'backport-1711-socket-fix-glib-2-66' into 'glib-2-66' · cfbab734
      Emmanuele Bassi authored
      Backport !1711 “Fix race in socketclient-slow test” to glib-2-66
      See merge request !1723
    • Michael Catanzaro's avatar
      Fix race in socketclient-slow test · 832d09ad
      Michael Catanzaro authored
      This test ensures that g_socket_client_connect_to_host_async() fails if
      it is cancelled, but it's not cancelled until after 1 millisecond. Our
      CI testers are hitting that race window, and Milan is able to reproduce
      the crash locally as well. Switching it from 1ms to 0ms is enough for
      Milan to avoid the crash, but not enough for our CI, so let's move the
      cancellation to a GSocketClientEvent callback where the timing is
      completely deterministic.
      Hopefully fixes #2221
  12. 26 Oct, 2020 2 commits
    • Philip Withnall's avatar
      Merge branch 'backport-1713-main-context-check-glib-2-66' into 'glib-2-66' · 614d4094
      Philip Withnall authored
      Backport !1713 “gmain: g_main_context_check() can skip updating polled FD sources” to glib-2-66
      See merge request !1721
    • Claudio Saavedra's avatar
      gmain: g_main_context_check() can skip updating polled FD sources · fa45688f
      Claudio Saavedra authored
      If there is a file descriptor source that has a lower priority
      than the one for sources that are going to be dispatched,
      all subsequent file descriptor sources (internally sorted by
      file descriptor identifier) do not get an update in their GPollRec
      and later on wrong sources can be dispatched.
      Fix this by first finding the first GPollRec that matches the current
      GPollFD, instead of relying on it to be the current one. At
      the same time, document the assumptions about the ordering of the
      file descriptor records and array and make explicit in the documentation
      that the array needs to be passed to g_main_context_check() as it was
      received from g_main_context_query().
      Added a new test that reproduces the bug by creating two file
      descriptor sources and an idle one. Since the first
      file descriptor created has a lower identifier and a low priority,
      the second one is not dispatched even when it has the same, higher,
      priority as the idle source. After fixing this bug, both
      higher priority sources are dispatched as expected.
      While this patch was written independently, a similar fix for this
      bug was first submitted by Eugene M in !562. Having a
      second fix that basically does the same is a reassurance that we
      are in the right here.
      Fixes #1592
  13. 23 Oct, 2020 2 commits
  14. 19 Oct, 2020 4 commits
  15. 16 Oct, 2020 5 commits
  16. 15 Oct, 2020 4 commits
    • Philip Withnall's avatar
      tests: Add a basic test for GTimeZone caching · 976f48b4
      Philip Withnall authored
      This tests the previous few commits.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <pwithnall@endlessos.org>
    • António Fernandes's avatar
      Revert "gtimezone: Cache timezones based on the identifier they were created by" · cfe593a3
      António Fernandes authored
      This reverts commit 851241f1.
      That commit avoids a performance regression but introduces a behavior regression:
      changes to /etc/localtime have no effect for the remaining of the application's
      With the optimization introduced by the previous commit, we can pass NULL to
      g_time_zone_new() repeatedly with no performance drawback, so we no longer have
      to workaround this case.
      Fixes: #2224
    • António Fernandes's avatar
      gtimezone: Cache default timezone indefinitely · 3ab278da
      António Fernandes authored
      We cache GTimeZone instances to avoid expensive construction when the
      same id is requested again.
      However, if the NULL id is passed to g_time_zone_new(), we always
      construct a new instance for the default/fallback timezone.
      With the recent introduction of some heavy calculations[1], repeated
      instance construction in such cases has visible performance impact in
      nautilus list view and other such GtkTreeView consumers.
      To avoid this, cache reference to a constructed default timezone and
      use it the next time g_time_zone_new() is called with NULL argument,
      as long as the default identifier doesn't change. We already did the
      same for the local timezone[2].
      Fixes: #2204
      Based on idea proposed by Sebastian Keller <skeller@gnome.org>.
      [1] 25d950b6
      [2] 551e8366
    • António Fernandes's avatar
      gtimezone: Set resolved_identifier earlier · 19c5e13f
      António Fernandes authored
      We have been passing a &resolved_identifier address around for multiple
      functions to set it. Each function may either:
          1.  leaving it for the next function to set, if returning early;
          2.  set it to a duplicate of the passed identifier, if not NULL;
          3.  get a fallback value and set it, otherwise.
      This can be simplified by setting it early to either:
          1.  a duplicate of the passed identifier, if not NULL;
          2.  a fallback value, otherwise.
      This way we can avoid some unnecessary string duplication and freeing.
      Also, on Windows, we avoid calling windows_default_tzname() twice.
      But the main motivation for this change is enabling the performance
      optimization in the next commit.