[Mlir-commits] [lldb] [llvm] [mlir] Split the llvm::ThreadPool into an abstract base class and an implementation (PR #82094)

[Georgios Pinitas]

================
@@ -227,7 +265,7 @@ class ThreadPool {
 class ThreadPoolTaskGroup {
----------------
GeorgeARM wrote:

Get the point of @aganea; the `ThreadPoolTaskGroup` is a bit tricky to reason when it comes to customized extensibility as the concrete implementation is injected to the interface itself. IMHO I think that this construct can sit on top of the `ThreadPoolInterface` itself (as it kind of does now) without semantically injecting itself in the pool. Someone can implement this through some API that returns a trackable construct; e.g. a `TaskID` or some kind of `Future` interface from the `asyncEnqueue`. Not sure if that's worth the effort though.

https://github.com/llvm/llvm-project/pull/82094