[Mlir-commits] [lldb] [llvm] [mlir] Split the llvm::ThreadPool into an abstract base class and an implementation (PR #82094)
Mehdi Amini
llvmlistbot at llvm.org
Tue Feb 27 12:25:24 PST 2024
================
@@ -227,7 +265,7 @@ class ThreadPool {
class ThreadPoolTaskGroup {
----------------
joker-eph wrote:
> Wouldn't the implemention for ThreadPoolTaskGroup come in hand with the one for ThreadPool?
Right now the only thing the TaskGroup provide is a unique ID in the form of its own address.
I don't quite get what I would change in the implementation? Would you want the group to customize its own `wait()`? Right now it dispatches to the threadpool implementation: `wait(ThreadPoolTaskGroup &Group)`.
Customizing the task group would require to change the pattern at every use site as well: https://github.com/llvm/llvm-project/blob/0e0bee26e7f33c065eebef9a674b2f19bb156414/mlir/include/mlir/IR/Threading.h#L69-L70
Instead of:
```
llvm::ThreadPool &threadPool = context->getThreadPool();
llvm::ThreadPoolTaskGroup tasksGroup(threadPool);
```
we would need to use the pool as a factory somehow:
```
llvm::ThreadPool &threadPool = context->getThreadPool();
std::unique_ptr<llvm::ThreadPoolTaskGroup> tasksGroup = threadPool.createTaskGroup();
```
I'm not opposed to this, but that still seems like a separate change, and one that would better be done when there is somehow with the need for this.
https://github.com/llvm/llvm-project/pull/82094
More information about the Mlir-commits
mailing list