1. 27 Apr, 2018 1 commit
  2. 24 May, 2017 1 commit
  3. 16 Mar, 2017 1 commit
  4. 10 Oct, 2014 1 commit
  5. 29 Aug, 2014 1 commit
  6. 28 Jun, 2014 1 commit
  7. 31 May, 2014 1 commit
  8. 15 Apr, 2014 1 commit
  9. 20 Feb, 2014 1 commit
  10. 02 Feb, 2014 1 commit
  11. 01 Feb, 2014 2 commits
  12. 31 Jan, 2014 1 commit
  13. 20 Jan, 2014 1 commit
  14. 19 Jan, 2014 1 commit
  15. 22 Jul, 2013 1 commit
  16. 03 Feb, 2013 1 commit
  17. 13 Jan, 2013 1 commit
  18. 28 Dec, 2012 1 commit
  19. 06 Dec, 2012 1 commit
  20. 01 Nov, 2012 1 commit
  21. 17 Aug, 2012 1 commit
  22. 03 Jul, 2012 1 commit
  23. 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
  24. 27 Feb, 2012 1 commit
  25. 02 Jan, 2012 1 commit
  26. 14 Dec, 2011 1 commit
  27. 03 Nov, 2011 2 commits
  28. 26 Oct, 2011 2 commits
  29. 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
  30. 17 Oct, 2011 3 commits
    • Allison Karlitskaya's avatar
      push G_THREADS_MANDATORY over the cliff · b0ab7aba
      Allison Karlitskaya authored
      This was used as an optimisation for the macro hackery that used to live
      in gthread.h.  If a particular library or program knew that it could
      rely on thread support being enabled, it would allow for static
      evaluation of conditionals in some of those macros.
      
      Since the macros are dead and thread support is now always-on, we can
      get rid of this bit of legacy.
      b0ab7aba
    • Allison Karlitskaya's avatar
      gthread/: fix up declarations · a6d9cf33
      Allison Karlitskaya authored
      g_thread_init() is now a deprecated API, so drop G_DISABLE_DEPRECATED
      from the CFLAGS for gthread/.  Add the missing declaration for
      g_thread_init_with_errorcheck_mutexes() back to deprecated/gthread.h.
      a6d9cf33
    • 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
  31. 16 Oct, 2011 1 commit
  32. 15 Oct, 2011 1 commit
  33. 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
  34. 13 Oct, 2011 1 commit