================
@@ -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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits