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

[Mehdi Amini via lldb-commits]

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

> Uniqueness is "guaranteed" through memory addressing. Someone can break uniqueness when going through the public ThreadPool API.


How so?

> Type safety; sure you don't have implicit conversions going on.


There is much more than: the API is constrained to say: "it operates on an instance of a TaskGroup object".
This is a very important API: it is explicit in terms of the scope on which it operates, and the fact that it care about the **actual instance** of the TaskGroup object.


> So what I think is that instead of passing *this you can convert the address to a string/int and pass this instead; hence you don't lose any guarantees. I understand your arguments but I find this a bit more decoupled.

As I said above, I would have strong concerns with this: it is a weak API (it is open to any integer and does not carry the semantics I described above) and "unsafe", just like using `void*`. 
There is not way for a user to know what integer to pass here for example. As a user such API is highly confusing and really I'm not sure what the pattern would be other than always casting the address of the task group to an int.



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