1. 25 Jun, 2020 17 commits
  2. 24 Jun, 2020 1 commit
  3. 23 Jun, 2020 12 commits
  4. 22 Jun, 2020 1 commit
  5. 19 Jun, 2020 5 commits
    • Philip Withnall's avatar
      Merge branch 'wip/oholy/remote-attribute-fixes' into 'master' · 97b5bc4a
      Philip Withnall authored
      Various GLocalFile fixes related to the filesystem::remote attribute
      
      See merge request !1534
      97b5bc4a
    • Philip Withnall's avatar
      gmain: Access Unix signal handler state atomically · 253f5cda
      Philip Withnall authored
      There are two variables which are used to pass state from the Unix
      signal handler interrupt function to the rest of `gmain.c`. They are
      currently defined as `sig_atomic_t`, which means that they are
      guaranteed to be interrupt safe. However, it does not guarantee they are
      thread-safe, and GLib attaches its signal handler interrupt function to
      a worker thread.
      
      Make them thread-safe using atomics. It’s not possible to use locks, as
      pthread mutex functions are not signal-handler-safe. In particular, this
      means we have to be careful not to end up using GLib’s fallback atomics
      implementation, as that secretly uses a mutex. Better to be unsafe than
      have a re-entrant call into `pthread_mutex_lock()` from a nested signal
      handler.
      
      This commit solves two problems:
       1. Writes to `any_unix_signal_pending` and `unix_signal_pending` could
          be delivered out of order to the worker thread which calls
          `dispatch_unix_signals()`, resulting in signals not being handled
          until the next iteration of that worker thread. This is a
          performance problem but not a correctness problem.
       2. Setting an element of `unix_signal_pending` from
          `g_unix_signal_handler()` and clearing it from
          `dispatch_unix_signals_unlocked()` (in the worker thread) could
          race, resulting in a signal emission being cleared without being
          handled. That’s a correctness problem.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      
      Fixes: #1670
      253f5cda
    • Ondrej Holy's avatar
      glocalfile: Add SMB on the list of remote filesystems · 92c99605
      Ondrej Holy authored
      The G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE is set to TRUE only for NFS
      filesystem types currently. Let's add also SMB filesystem types. This
      also changes g_local_file_is_nfs_home function logic to handle only
      NFS filesystems.
      92c99605
    • Ondrej Holy's avatar
      glocalfile: Rename g_local_file_is_remote · a8f97cbe
      Ondrej Holy authored
      The g_local_file_is_remote function is misleading as it works only for
      NFS filesystem types and only for locations in home directorly. Let's
      rename it to g_local_file_is_nfs_home to make it obvious.
      a8f97cbe
    • Ondrej Holy's avatar
      glocalfile: Do not call statfs/statvfs several times · f489f6c4
      Ondrej Holy authored
      statfs/statvfs is called several times when querying filesystem info.
      This is because the G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE attribute is set
      over is_remote_fs function, which calls statfs/statvfs again. Let's use
      the already known fstype instead of redundant statfs/statvfs calls.
      This also changes g_local_file_is_remote implementation to use
      g_local_file_query_filesystem_info to obtain fstype, which allows to
      remove duplicated code from is_remote_fs function.
      f489f6c4
  6. 18 Jun, 2020 4 commits