Repository navigation
docs: describe thread_pool shutdown accurately - #458
Conversation
|
An automated preview of the documentation is available at https://458.capy.prtest3.cppalliance.org/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-10-20 20:09:17 UTC |
|
GCOVR code coverage report https://458.capy.prtest3.cppalliance.org/gcovr/index.html Build time: 2026-10-20 20:34:22 UTC |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #458 +/- ##
========================================
Coverage 98.47% 98.47%
========================================
Files 137 137
Lines 7293 7293
========================================
Hits 7182 7182
Misses 111 111
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
Rewrite the ~thread_pool documentation. It gives the steps in order: stop the pool, join the worker threads, then shut down the services and abandon the queued work. The destructor does not wait for outstanding work. Each abandoned chain unwinds on the executor of the coroutine that started it. The documentation also gives the relation to join(). Add a precondition: a thread of the pool must not destroy the pool. Correct these other statements in thread_pool.hpp: - The destructor precondition names only run_async. The run function does not add outstanding work to the pool. The precondition also tells the user not to call stop(), because join() then does not wait for outstanding work. - join() has no internal work guard to release. - A join() call that occurs while another join() call blocks returns immediately. Only the first call joins the threads. - post() does not run a continuation after the pool stops. The destructor abandons it. dispatch() does the same when it posts. - post() and dispatch() can throw std::system_error when they start the worker threads. Then the continuation is not queued. - The executor_type brief gives what the class does. Correct two example comments and the allocators page. The destructor abandons queued work. It does not discard it. pool.join() does not release the task frames. It returns after the task releases them. Closes cppalliance#404
72bfccb to
189986e
Compare
3 participants
Rewrite the ~thread_pool documentation. It gives the steps in order: stop the pool, join the worker threads, then shut down the services and abandon the queued work. The destructor does not wait for outstanding work. Each abandoned chain unwinds on the executor of the coroutine that started it. The documentation also gives the relation to join(). Add a precondition: a thread of the pool must not destroy the pool.
Correct these other statements in thread_pool.hpp:
Correct two example comments and the allocators page. The destructor abandons queued work. It does not discard it. pool.join() does not release the task frames. It returns after the task releases them.
Closes #404