aboutsummaryrefslogtreecommitdiffhomepage
path: root/include/core/SkExecutor.h
Commit message (Collapse)AuthorAge
* Add FIFO thread pool, use it for most things.Gravatar Mike Klein2017-09-01
| | | | | | | | | | | | | | | | | | | We like a LIFO default thread pool in tools like DM for better memory/time locality... the bots use less memory this way, and generally run faster. But most use cases want a FIFO queue, so that they can get going on the next parts of early work while later work is still running. This splits the implementation into one using SkTArray and pop_back for LIFO, and a new one using std::deque and pop_front for FIFO. Change-Id: Ief203b6869a00f1f8084019431a781d15fc63750 Reviewed-on: https://skia-review.googlesource.com/41849 Commit-Queue: Mike Klein <mtklein@chromium.org> Commit-Queue: Brian Osman <brianosman@google.com> Reviewed-by: Yuqian Li <liyuqian@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
* SkExecutorGravatar Mike Klein2017-02-22
Refactoring to refamiliarize myself with SkTaskGroup and SkThreadPool. This adds an SkExecutor interface to describe how we use SkThreadPool, with a global setter and getter for a default instance. Then I rewrote SkTaskGroup to work with any executor, the global default by default. I also think I've made the SkTaskGroup::wait() borrow logic clearer with the addition of SkSemaphore::try_wait(). This lets me keep the semaphore count and actual count of work in perfect sync. Change-Id: I6bbdfaeb0e2c3a43daff6192d34bc4a3f7210178 Reviewed-on: https://skia-review.googlesource.com/8836 Reviewed-by: Mike Reed <reed@google.com> Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@chromium.org>