From 75b9f1dedc7d22ee71478e30de121f2c526b4b39 Mon Sep 17 00:00:00 2001
From: Scott Wolchok <swolchok@fb.com>
Date: Thu, 26 Sep 2024 16:41:48 -0700
Subject: [PATCH] [ExecuTorch] Fix non-reentrant threadpool

If we tried to reenter parallel_for, we would deadlock due to trying to acquire the threadpool mutex, which was already held. Removing the mutex (which is unnecessary) didn't fix the problem because pthreadpool has its own internal mutex.

Differential Revision: [D62052200](https://our.internmc.facebook.com/intern/diff/D62052200/)

[ghstack-poisoned]
---
 extension/threadpool/threadpool.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/extension/threadpool/threadpool.cpp b/extension/threadpool/threadpool.cpp
index e8f2ea5f704..f14ce284a64 100644
--- a/extension/threadpool/threadpool.cpp
+++ b/extension/threadpool/threadpool.cpp
@@ -86,6 +86,7 @@ void ThreadPool::run(
       // pthreadpool_parallelize_1d() cannot go out of scope until
       // pthreadpool_parallelize_1d() returns.
       [](void* const context, const size_t item) {
+        NoThreadPoolGuard guard;
         reinterpret_cast<Context*>(context)->fn(item);
       },
       &context,