1. 14 Jul, 2022 3 commits
  2. 13 Jul, 2022 4 commits
  3. 12 Jul, 2022 19 commits
  4. 11 Jul, 2022 3 commits
    • Marco Trevisan's avatar
      gthreadpool: Update unused_threads while we still own the pool lock · a275ee66
      Marco Trevisan authored
      As per the rationale explained in the previous commit, we could end up
      having the unused_threads value not to be conformant to what
      g_thread_pool_get_num_threads() returns, because an about-to-be-unused
      thread might not be counted yet as such, while the pool threads number
      has been already decreased.
      
      To avoid such scenario, and to make sure that when all the pool's
      threads are stopped, they're unmarked as unused, let's increase the
      unused_threads value earlier, while we still own the pool lock so that
      it will always include the pool that is not used anymore, but not yet
      queued.
      
      As per this we can update the test, not to repeat the stop-unused call
      as now we're sure that when the pool has no threads anymore, the unused
      threads value is also updated accordingly.
      
      Also adding a tests with multiple pools.
      a275ee66
    • Marco Trevisan's avatar
      glib/test/thread-pool-slow: Ensure all unused threads are really stopped · fabdc2d4
      Marco Trevisan authored
      In this tests we wanted to ensure that all the unused threads were
      stopped, however while we were calling g_thread_pool_stop_unused_threads
      some threads could still be in the process of being recycled even tough
      the pool's num_thread values are 0.
      
      In fact, stopping unused threads implies also resetting back the max
      unused threads to the previous value, and in this test it caused it to
      go from -1 -> 0 and back to -1, after killing the unused threads we
      knew about; thus any about-to-be-unused thread that is not killed during
      this call will be just left around as a waiting unused thread afterwards.
      
      However, if this function was getting called when a thread was in
      between of calling the user function and the moment it was being
      recycled (and so when the pool num_threads was updated), but this thread
      was not counted in unused_threads, we ended up in having a race because
      all the threads were consumed from our POV, but some were actually not
      yet unused, and so were kept waiting forever for some new job.
      
      To avoid this in the test, we can ensure that we stop the unused
      threads until we the number of them is really 0.
      
      Sadly we need to repeat this as we don't have a clear point in which we
      are sure about the fact that our threads are done, while it would be
      wrong to stop a thread that is technically not yet marked as unused.
      
      We could also do this in g_thread_pool_stop_unused_threads() itself, but
      it would make such function to wait for threads to complete, and this is
      probably not what was expected in the initial API.
      
      Fixes: #2685
      fabdc2d4
    • Marco Trevisan's avatar
      glib/tests/thread-pool-slow: Fix indentation in test_thread_stop_unused · a5ccaa05
      Marco Trevisan authored
      It used three-spaces indentation instead of 2, fix it.
      a5ccaa05
  5. 08 Jul, 2022 10 commits
  6. 07 Jul, 2022 1 commit
    • Philip Withnall's avatar
      gmain: Use waitid() on pidfds rather than a global SIGCHLD handler · f615eef4
      Philip Withnall authored
      When the system supports it (as all Linux kernels ≥ 5.3 should), it’s
      preferable to use `pidfd_open()` and `waitid()` to be notified of
      child processes exiting or being signalled, rather than installing a
      default `SIGCHLD` handler.
      
      A default `SIGCHLD` handler is global, and can never interact well with
      other code (from the application or other libraries) which also wants to
      install a `SIGCHLD` handler.
      
      This use of `pidfd_open()` is racy (the PID may be reused between
      `g_child_watch_source_new()` being called and `pidfd_open()` being
      called), so it doesn’t improve behaviour there. For that, we’d need
      continuous use of pidfds throughout GLib, from fork/spawn time until
      here. See #1866 for that.
      
      The use of `waitid()` to get the process exit status could be expanded
      in future to also work for stopped or continued processes (as per #175
      
      )
      by adding `WSTOPPED | WCONTINUED` into the flags. That’s a behaviour
      change which is outside the strict scope of adding pidfd support,
      though.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <pwithnall@endlessos.org>
      
      Helps: #1866
      Fixes: #2216
      f615eef4