zhztheplayer commented on code in PR #13115:
URL: https://github.com/apache/gluten/pull/13115#discussion_r4120247771
##########
cpp/velox/compute/VeloxBackend.cc:
##########
@@ -328,6 +329,18 @@ ReaderThreadPool* VeloxBackend::getReaderThreadPool() {
return readerThreadPool_.get();
}
+folly::Executor* VeloxBackend::hashTableBuildExecutor() {
+ std::call_once(hashTableBuildExecutorInit_, [this] {
+ auto numThreads = backendConf_->get<int32_t>(kHashTableBuildThreads,
kHashTableBuildThreadsDefault);
+ if (numThreads <= 0) {
+ // Parallel builds still need a worker when there are no task slots.
+ numThreads = std::max<int32_t>(1,
backendConf_->get<int32_t>(kNumTaskSlotsPerExecutor, 1));
+ }
+ hashTableBuildExecutor_ =
std::make_unique<folly::CPUThreadPoolExecutor>(numThreads);
+ });
+ return hashTableBuildExecutor_.get();
+}
Review Comment:
> hashTableBuildExecutor_ is only used during native build, so lazy
initialization is a better choice here, what do you think?
The thread creation should already be lazy in
`folly::CPUThreadPoolExecutor`, so I assume
`std::make_unique<folly::CPUThreadPoolExecutor>(numThreads)` is a cheap
operation?
I asked the question mainly because it's not aligned with initialization
code of other executors.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
