1. 05 Jan, 2021 1 commit
  2. 30 Sep, 2020 1 commit
  3. 02 Sep, 2020 1 commit
  4. 24 Feb, 2020 1 commit
  5. 12 Feb, 2020 1 commit
  6. 19 Jan, 2020 1 commit
  7. 16 Jan, 2020 1 commit
  8. 15 Jan, 2020 1 commit
    • Sebastian Dröge's avatar
      GThreadPool - Don't inherit thread priorities when creating new threads · 8aeca4fa
      Sebastian Dröge authored
      By default (on POSIX) we would be inheriting thread priorities from the
      thread that pushed a new task on non-exclusive thread pools and causes a
      new thread to be created. This can cause any non-exclusive thread pool
      to accidentally contain threads of different priorities, or e.g. threads
      with real-time priority.
      To prevent this, custom handling for setting the scheduler settings for
      Linux and Windows is added and as a fallback for other platforms a new
      thread is added that is responsible for spawning threads for
      non-exclusive thread pools.
      Fixes #1834
  9. 21 Sep, 2019 1 commit
    • Philip Withnall's avatar
      gatomic: Add various casts to use of g_atomic_*()s to fix warnings · 55f9c6d2
      Philip Withnall authored
      When compiling GLib with `-Wsign-conversion`, we get various warnings
      about the atomic calls. A lot of these were fixed by
      3ad375a6, but some remain. Fix them by
      adding appropriate casts at the call sites.
      Note that `g_atomic_int_{and,or,xor}()` actually all operate on `guint`s
      rather than `gint`s (which is what the rest of the `g_atomic_int_*()`
      functions operate on). I can’t find any written reasoning for this, but
      assume that it’s because signedness is irrelevant when you’re using an
      integer as a bit field. It’s unfortunate that they’re named a
      `g_atomic_int_*()` rather than `g_atomic_uint_*()` functions.
      Tested by compiling GLib as:
      CFLAGS=-Wsign-conversion jhbuild make -ac |& grep atomic
      I’m not going to add `-Wsign-conversion` to the set of default warnings
      for building GLib, because it mostly produces false positives throughout
      the rest of GLib.
      Signed-off-by: Philip Withnall <...
  10. 29 Aug, 2019 1 commit
  11. 02 Jul, 2019 1 commit
    • Allison Karlitskaya's avatar
      gthread: fix minor errno problem in GCond · d92f22ab
      Allison Karlitskaya authored
      The return value from `g_cond_wait_until()` is calculated, based on the
      value of `errno` after reacquiring the mutex.  This is a problem because
      `errno` can be overwritten in the case the mutex is contended (in which
      case the slow-path code will re-enter the kernel).
      Perform the calculation before reacquiring the mutex.
      See merge request !958
  12. 31 May, 2019 1 commit
  13. 17 Mar, 2019 1 commit
    • Emmanuel Fleury's avatar
      Fixing signedness in glib/gthread-posix.c · 5dd02cc6
      Emmanuel Fleury authored
      In file included from glib/glibconfig.h:9,
                       from glib/gtypes.h:32,
                       from glib/gatomic.h:27,
                       from glib/gthread.h:32,
                       from glib/gthread-posix.c:42:
      glib/gthread-posix.c: In function ‘g_system_thread_new’:
      glib/gmacros.h:348:26: error: comparison of integer expressions of different signedness: ‘long int’ and ‘gulong’ {aka ‘long unsigned int’} [-Werror=sign-compare]
       #define MAX(a, b)  (((a) > (b)) ? (a) : (b))
      glib/gthread-posix.c:1169:22: note: in expansion of macro ‘MAX’
               stack_size = MAX (min_stack_size, stack_size);
      glib/gmacros.h:348:35: error: operand of ?: changes signedness from ‘long int’ to ‘gulong’ {aka ‘long unsigned int’} due to unsignedness of other operand [-Werror=sign-compare]
       #define MAX(a, b)  (((a) > (b)) ? (a) : (b))
      glib/gthread-posix.c:1169:22: note: in expansion of macro ‘MAX’
               stack_size = MAX (min_stack_size, stack_size);
  14. 31 Jan, 2019 1 commit
    • Colin Walters's avatar
      gthread: Rework to avoid holding a mutex half the time · 630fa82e
      Colin Walters authored
      This code was a persistent source of `-fsanitize=thread` errors
      when I was trying to use it on OSTree.
      The problem is that while I think this code is functionally correct,
      we hold a mutex during the writes, but not the reads, and TSAN (IMO
      correctly) flags that.
      Reading this, I don't see a reason we need a mutex at all.  At the
      cost of some small code duplication between posix/win32, we can just
      pass the data we need down into each implementation.  This ends up
      being notably cleaner I think than the awkward "lock/unlock to
      serialize" dance.
      (Minor review changes made by Philip Withnall <withnall@endlessm.com>.)
  15. 06 Feb, 2018 1 commit
  16. 12 Nov, 2017 1 commit
  17. 03 Nov, 2017 1 commit
  18. 26 Oct, 2017 1 commit
  19. 24 May, 2017 1 commit
    • Sébastien Wilmet's avatar
      glib/: LGPLv2+ -> LGPLv2.1+ · f9faac76
      Sébastien Wilmet authored
      All glib/*.{c,h} files have been processed, as well as gtester-report.
      12 of those files are not licensed under LGPL:
      Some of them are generated files, some are licensed under a BSD-style
      license and win_iconv.c is in the public domain.
      Sub-directories inside glib/:
      	deprecated/: processed in a previous commit
      	glib-mirroring-tab/: already LGPLv2.1+
      	gnulib/: not modified, the code is copied from gnulib
      	libcharset/: a copy
      	pcre/: a copy
      	tests/: processed in a previous commit
  20. 27 Apr, 2016 1 commit
  21. 26 Apr, 2016 2 commits
  22. 29 May, 2015 1 commit
  23. 13 Mar, 2015 1 commit
  24. 26 Jan, 2015 1 commit
  25. 09 Jul, 2014 3 commits
  26. 06 Jun, 2014 1 commit
  27. 20 May, 2014 1 commit
  28. 21 Feb, 2014 1 commit
  29. 20 Feb, 2014 1 commit
    • Allison Karlitskaya's avatar
      Fix g_cond_wait_until() vs. monotonic time · 1de36e77
      Allison Karlitskaya authored
      We've had a relatively rocky path with g_cond_wait_until() on systems
      that either don't support pthread_condattr_setclock() or where
      g_get_monotonic_time() is not based on CLOCK_MONOTONIC (ie: Android and
      Mac OS).
      Fortunately, both of these platforms seem to share
      pthread_cond_timedwait_relative_np() which allows us to implement
      g_cond_wait_until() without races.
      With this patch, we now require that one of pthread_condattr_setclock()
      or pthread_cond_timedwait_relative_np() exists.  A quick look around
      suggests that this is true for all platforms that we care about.
      This patch removes our use of pthread_cond_timedwait_monotonic() and
      pthread_cond_timedwait_monotonic_np() which were Android-only APIs.
  30. 15 Feb, 2014 1 commit
    • Matthias Clasen's avatar
      docs: let go of &ast; · bc6ee788
      Matthias Clasen authored
      Since we are no longer using sgml mode, using /&ast; &ast;/ to
      escape block comments inside examples does not work anymore.
      Switch to using line comments with //
  31. 01 Feb, 2014 3 commits
  32. 31 Jan, 2014 2 commits
  33. 26 Nov, 2013 1 commit
  34. 20 Nov, 2013 1 commit
    • Dan Winship's avatar
      Require POSIX.1 (1990) compliance on unix · 3981cddb
      Dan Winship authored
      Assume unix platforms support the original POSIX.1 standard.
      Specifically, assume that if G_OS_UNIX, then we have chown(),
      getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>,
      <sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>.
      Additionally, since all versions of Windows that we care about also
      have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere.
      Also remove one include of <sys/times.h>, and the corresponding
      configure check, since the include is not currently needed (and may
      always have just been a typo for <sys/time.h>).