1. 22 Jun, 2017 8 commits
  2. 14 Jun, 2017 1 commit
  3. 01 Jun, 2017 2 commits
  4. 24 May, 2017 2 commits
    • Chun-wei Fan's avatar
      Visual Studio builds: Redo utility script generation · 958902ed
      Chun-wei Fan authored
      Use the new gen_util_scripts.py script to generate the glib-mkenums and
      gdbus-codegen scripts with the proper info in them so that they can be
      used properly by other build systems such as Meson, during "install".
      958902ed
    • Chun-wei Fan's avatar
      Visual Studio builds: Add script to generate utility scripts · b095df45
      Chun-wei Fan authored
      This will allow the utility scripts glib-mkenums and gdbus-codegen be
      generated with the proper info in them, as build systems such as Meson
      might look for shebang lines to determine the commands that need to be
      called to invoke the scripts (which is necessary for calling these
      scripts on standard Windows cmd.exe)
      b095df45
  5. 11 May, 2017 3 commits
    • Ignacio Casal Quinteiro's avatar
      Revert "GSocket: Fix race conditions on Win32 if multiple threads are waiting... · bae70d74
      Ignacio Casal Quinteiro authored
      Revert "GSocket: Fix race conditions on Win32 if multiple threads are waiting on conditions for the same socket"
      
      This reverts commit 799f8dcd.
      This patch seems to break applications that use GTask specific
      operations with GSocket. We will need to investigate a bit more
      on this issue but for now we revert it and leave it for the
      next major release.
      bae70d74
    • Philip Withnall's avatar
      gmain: Allow GSource methods to be called from a finalize() callback · c5890840
      Philip Withnall authored
      
      
      Temporarily increase the ref count of a GSource to 1 while calling its
      finalize() callback, so that the finalize() implementation can call
      GSource methods (like g_source_set_ready_time()) without causing
      critical warnings. It’s safe to call those methods at this point, as the
      source has been destroyed, but nothing has been freed.
      
      This is an indirect way of fixing a race between GCancellable and
      GCancellableSource, whereby the GCancellable::cancelled callback for the
      GCancellableSource is not disconnected until the GCancellableSource’s
      finalize() function is called. Previously, this meant there was a window
      in which the GCancellableSource’s ref count was 0, but the ::cancelled
      callback was still connected, and could legitimately be called as a
      result of another thread calling g_cancellable_cancel() on the
      GCancellable. The callback calls g_source_set_ready_time() on the
      GSource, and there’s no thread-safe way of checking whether the GSource
      has been destroyed. Instead, we have to change GSource so its ref count
      is only decremented to 0 inside the locked section in
      g_source_unref_internal() *after* the finalize() function has been
      called, and hence after the GCancellable::cancelled callback has been
      disconnected. The use of g_cancellable_disconnect() ensures that the
      callback disconnection is thread safe.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      
      https://bugzilla.gnome.org/show_bug.cgi?id=781601
      c5890840
    • Paolo Bonzini's avatar
      gmain: only signal GWakeup right before or during a blocking poll · 5d742334
      Paolo Bonzini authored and Philip Withnall's avatar Philip Withnall committed
      Since commit e4ee3079 ("Do not wake up main loop if change is from same
      thread", bug 761102), GMainContext uses context->owner to decide if the
      event loop is being run in the current thread.  However, what really
      matters is the phase in the prepare/query/poll/check/dispatch sequence.
      Wakeups are only needed between the end of prepare and the end of poll,
      and then only if prepare found that no sources were ready.
      
      There is no need to take threads into account, because prepare, check
      and all callers of conditional_wakeup all look at the new need_wakeup
      flag inside LOCK_CONTEXT/UNLOCK_CONTEXT.
      
      With this change, g_main_context_is_owner and g_main_context_wait are
      the only functions for which acquire/release matters, just like before
      commit e4ee3079
      
      .
      Signed-off-by: Paolo Bonzini's avatarPaolo Bonzini <bonzini@gnu.org>
      5d742334
  6. 10 May, 2017 1 commit
    • Chun-wei Fan's avatar
      win32/replace.py: Fix replacing items in files with UTF-8 content · 21be268a
      Chun-wei Fan authored
      Some files that this script will process might have UTF-8 items in
      there, which can cause problems on Python 3.x as it is more strict and
      careful on unicode issues.  Fix this by:
      
      -Doing what we did before on Python 2.x
      -Open the file with encoding='utf-8' on Python 3.x
      21be268a
  7. 09 May, 2017 1 commit
    • Ondrej Holy's avatar
      gunixmounts: Prevent unwanted automount requests · b8bd46bc
      Ondrej Holy authored
      mnt_table_is_fs_mounted causes unwanted automount requests due to
      canonicalization of source and target. It might be replaced by
      mnt_table_find_source as per the documentation in order to prevent
      the automounts, but it is redundant. All mtab entries should be already
      mounted and thus mnt_table_is_fs_mounted result is always true (it
      basically checks that the fs from mtab is in mtab). Let's remove
      the check at all.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=781867
      b8bd46bc
  8. 08 May, 2017 1 commit
  9. 02 May, 2017 1 commit
    • Matthias Clasen's avatar
      portal support: Raise the priority for network monitor · 3a6811a4
      Matthias Clasen authored
      When we are inside a sandbox, we want to use the portal
      implementation, since it is the only one that has a chance
      of working.
      
      This is safe to do, since the portal implementation will
      just fail initialization when loaded outside a sandbox.
      3a6811a4
  10. 28 Apr, 2017 6 commits
  11. 18 Apr, 2017 1 commit
  12. 16 Apr, 2017 1 commit
  13. 11 Apr, 2017 2 commits
  14. 08 Apr, 2017 10 commits