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

[Mehdi Amini]

================
@@ -92,30 +104,32 @@ class ThreadPool {
                      &Group);
   }
 
-  /// Blocking wait for all the threads to complete and the queue to be empty.
-  /// It is an error to try to add new tasks while blocking on this call.
-  /// Calling wait() from a task would deadlock waiting for itself.
-  void wait();
+private:
+  /// Asynchronous submission of a task to the pool. The returned future can be
+  /// used to wait for the task to finish and is *non-blocking* on destruction.
+  template <typename ResTy>
+  std::shared_future<ResTy> asyncImpl(std::function<ResTy()> Task,
+                                      ThreadPoolTaskGroup *Group) {
 
-  /// Blocking wait for only all the threads in the given group to complete.
-  /// It is possible to wait even inside a task, but waiting (directly or
-  /// indirectly) on itself will deadlock. If called from a task running on a
-  /// worker thread, the call may process pending tasks while waiting in order
-  /// not to waste the thread.
-  void wait(ThreadPoolTaskGroup &Group);
+#if LLVM_ENABLE_THREADS
+    /// Wrap the Task in a std::function<void()> that sets the result of the
+    /// corresponding future.
+    auto R = createTaskAndFuture(Task);
 
-  // Returns the maximum number of worker threads in the pool, not the current
-  // number of threads!
-  unsigned getMaxConcurrency() const { return MaxThreadCount; }
+    asyncEnqueue(std::move(R.first), Group);
+    return R.second.share();
 
-  // TODO: misleading legacy name warning!
-  LLVM_DEPRECATED("Use getMaxConcurrency instead", "getMaxConcurrency")
-  unsigned getThreadCount() const { return MaxThreadCount; }
+#else // LLVM_ENABLE_THREADS Disabled
----------------
joker-eph wrote:

Right so the part about:

> creating a factory function for the default pool implementation, but that would force updating every users to initialize with something like:std::unique_ptr<ThreadPoolInterface> = llvm::makeThreadPool(options); (and every following uses to be pointer based).

makes this non-practical to me right now. Do you have concrete ideas about making this palatable?

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