1. 09 Mar, 2012 1 commit
    • Mark Janossy's avatar
      deprecated threads: fix race in GStaticRecMutex · 265f265c
      Mark Janossy authored
      The very last access to the 'depth' field of GStaticRecMutex in
      g_static_rec_mutex_unlock_full() was being performed after dropping the
      implementation mutex for the last time.
      
      This allowed the lock to be dropped an additional time if it was
      acquired in another thread right at that instant (which is somewhat
      likely, since another thread could have just been woken up by the lock
      being released).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=670846
      265f265c
  2. 14 Dec, 2011 1 commit
  3. 19 Oct, 2011 1 commit
    • Allison Karlitskaya's avatar
      Fix bug in g_static_rec_mutex_unlock_full() · 99f0eaa4
      Allison Karlitskaya authored
      pthreads doesn't implement the _lock_full() and _unlock_full() calls on
      recursive mutexes so we don't have it on GRecMutex either.  Now that
      we're using GRecMutex to implement GStaticRecMutex, we have to fake it
      by keeping an internal counter of the number of locks and calling
      g_rec_mutex_unlock() the appropriate number of times.
      
      The code to do this looked like:
      
        depth = mutex->depth;
        while (mutex->depth--)
          g_rec_mutex_unlock (rm);
        return depth;
      
      which unfortunately did one last decrement after mutex->depth was
      already zero (leaving it equal to -1).
      
      When locked the next time, the count would then increase from -1 to 0
      and then the next _unlock_full() call would not do any calls to
      g_rec_mutex_unlock(), leading to a deadlock.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=661914
      99f0eaa4
  4. 17 Oct, 2011 1 commit
    • Allison Karlitskaya's avatar
      Add private prototype for g_thread_init_glib() · 3eec796b
      Allison Karlitskaya authored
      This function was never put in a header and was only used internally
      from libgthread, but we should keep the symbol around to avoid
      triggering any false-positives on ABI checkers.
      
      For -Wmissing-prototypes compatibility with this unusual case, we should
      add a private prototype in the .c file just before.
      3eec796b
  5. 15 Oct, 2011 1 commit
  6. 14 Oct, 2011 2 commits
    • Allison Karlitskaya's avatar
      g_cond_timed_wait: support NULL time parameter · 14e3b128
      Allison Karlitskaya authored
      It was undocumented, but this used to mean "wait forever".  Looks like
      we have some uses of this internally and there may be others in the
      wild...
      14e3b128
    • Allison Karlitskaya's avatar
      GCond: use monotonic time for timed waits · 4033c616
      Allison Karlitskaya authored
      Switch GCond to using monotonic time for timed waits by introducing a
      new API based on monotonic time in a gint64: g_cond_wait_until().
      
      Deprecate the old API based on wallclock time in a GTimeVal.
      
      Fix up the gtk-doc for GCond while we're at it: update the examples to
      use static-allocated GCond and GMutex and clarify some things a bit.
      Also explain the rationale behind using an absolute time instead of a
      relative time.
      4033c616
  7. 13 Oct, 2011 5 commits
  8. 12 Oct, 2011 9 commits
  9. 10 Oct, 2011 1 commit
    • Allison Karlitskaya's avatar
      GStaticMutex: ABI fixup · 3e5a30fc
      Allison Karlitskaya authored
      Everything was OK as long as GMutex was backed by pthread_mutex_t on
      POSIX.  Since this is no longer the case, the ABI of GStaticMutex was
      broken.
      
      Fix that up by using pthread_mutex_t directly in the structure.  Since
      that's potentially incompatible with our GMutex implementation, set
      g_thread_use_default_impl to FALSE to cause the fallback code (which
      manually allocates a GMutex) to run, even in the case of
      already-existing code (without the need for a recompile).  This will
      cause the pthread_mutex_t part of the struct to be completely ignored.
      3e5a30fc
  10. 09 Oct, 2011 1 commit
  11. 06 Oct, 2011 3 commits
  12. 05 Oct, 2011 1 commit
  13. 04 Oct, 2011 2 commits
  14. 03 Oct, 2011 5 commits
  15. 25 Sep, 2011 1 commit