[llvm] [Support] Join threads when stopping the ThreadPoolExecutor (PR #166054)

[Maurice Heumann via llvm-commits]

momo5502 wrote:

> > I'm not sure if it happens in any current LLVM tool. For me this only happens when compiling LLVM as a DLL. Reproducing it is relatively easy, as mentioned here: [#166054 (comment)](https://github.com/llvm/llvm-project/pull/166054#issuecomment-3485814704) It just requries compiling LLVM as DLL and scheduling a task on the pool that takes a bit longer. At the end, it's a race condition, so it all depends on if the threads are still alive when the DLL is unloaded. As mentioned, turning that into a unittest turns out to be really tricky.
> 
> I'm not asking for a unit test, just an example to reproduce the issue. In "normal" operation, the thread that calls these parallel methods waits for completion, so normally the executor threads would be inactive but still "alive". However, I guess depending on how the process is exiting, the threads could potentially be executing code that is being unloaded?
> 
> I have compiled LLVM as a DLL and at least LLD, which I believe is still the main user of these parallel methods, appears to be exiting fine.

I have a sample for you.

Compile this as test.dll:

```C++
#include "llvm/Support/InitLLVM.h"
#include "llvm/Support/Parallel.h"

using namespace llvm;

extern "C" __declspec(dllexport) void schedule_task() {
  InitLLVM _{__argc, __argv};
  parallel::TaskGroup tg;
  tg.spawn([]() {});
}
```

and this as test.exe:

```C++
#include <Windows.h>

int main() {
  auto *h = LoadLibraryA("test.dll");
  auto *f = GetProcAddress(h, "schedule_task");

  ((void (*)())f)();

  FreeLibrary(h);
}
```

If you run the test.exe, it will deadlock in about 1/10 runs for me.

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