monzero-core.git/src/common/threadpool.cpp, branch v0.14.0.2Monzero core node, command-line wallet, consensus code, and release tooling.
https://code.monzero.org/monzero-core.git/atom?h=v0.14.0.22018-09-27T17:29:02Zthreadpool: do not propagate exceptions through the dtor2018-09-27T17:29:02Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2018-09-27T15:14:51Zurn:sha1:ea7f9543817993e22faf94478f07aac746729f73
This would call terminate.
We ignore exceptions in pthread_join instead, as this is not
a fatal problem here.
Coverity 182568
threadpool: allow leaf functions to run concurrently2018-06-26T21:15:22Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2018-04-26T10:44:47Zurn:sha1:2771a18e85bd91dd881f89f6c14d26cba35a1844
Decrease the number of worker threads by one to account
for the fact the calling thread acts as a worker thread now
threadpool: allow constructing an object, and misc tweaks2018-05-20T11:06:03Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2018-04-23T17:53:38Zurn:sha1:db55263b4c25a5014ce72aa1b601cfdebfe5d176
use unsigned int to avoid having to range check negative numbers,
use const where possible, don't needlessly create empty objects,
use std::move where possible
threadpool: catch exceptions in dtor, to avoid terminate2018-02-02T16:27:39Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2018-02-02T16:16:43Zurn:sha1:9b98a6ac8f750f5d786fe9a3a561373ca64e5049
If an exception is thrown, it is ignored. While this may hide
a bug, this should only be system exceptions in boost, which
is pretty unlikely. Morever, wait should be called manually
before the dtor anyway. Add an error message if the dtor has
to wait in case some such cases creep in so they get fixed.
Coverity 182538
Readd copyright starting date2018-01-26T15:03:20Zxmr-ericeric@moneroeric.com2018-01-07T23:55:52Zurn:sha1:84a7f6a4827f5baec6bb5cecbe11d4f61708b520Update 2018 copyright2018-01-26T15:03:20Zxmr-ericeric@moneroeric.com2018-01-07T05:05:16Zurn:sha1:18216f19dd479466cb7fd38f52d23bddfcfd4880threadpool: fix deadlock in recursive waiter usage2017-12-23T09:00:43Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2017-12-22T11:27:52Zurn:sha1:c70e8daa91fdcb17791f1c2b6e4119b1ab8074ab
If a queued job uses a waiter, then we want to run that waiter's
jobs in the current thread if all threads are busy, even if the
queue is empty, since there is no guarantee that any thread will
free up to take care of that new job, since all the threads might
be running a job which spawns such a recursive job and will block
till that recursive job is done, which it will never be since it
relies on the queue being polled by one of those blocked threads.
Use max_concurrency as-is2017-11-02T16:33:48ZHoward Chuhyc@symas.com2017-10-30T18:06:05Zurn:sha1:6738753b3054aa69a4b585d3d9c1fdbd2b0824d4
Don't try to 2nd guess user
Tweak concurrency limits2017-09-14T23:28:48ZHoward Chuhyc@symas.com2017-09-14T23:28:48Zurn:sha1:6d0ca7d11f18d1d842ec1ac639da4309ae41a83f
Create capacity for 2x max, but lie about it
Use a threadpool2017-09-14T20:42:48ZHoward Chuhyc@symas.com2017-09-14T03:39:37Zurn:sha1:510d0d47537aea8eff2e9c855099c4d4839cef32
Instead of constantly creating and destroying threads