[PATCH] D53968: [LLD]fix windows mingw build with 'LLVM_LINK_LLVM_DYLIB' the lld will hang when exiting

[Martin Storsjö via Phabricator via llvm-commits]

mstorsjo added a comment.

In https://reviews.llvm.org/D53968#1284789, @ruiu wrote:

> I think it is OK to wrap these objects with ManagedStatic as long as it fixes a crash bug and doesn't do any harm.


If I understand this correctly, this change makes lld on all other platforms to clean up the default thread pool executor in the call to `llvm_shutdown()` in `exitLld()`, before calling `_exit()`. So it potentially has some performance effect for other platforms.

Btw, it does indeed seem that you can't repro this issue by changing `_exit()` into `exit()`, I was mistaken about this.

After looking a bit closer at the repro example, as far as I understand it, the main issue is that you cannot do threading cleanup from within a DLL unload handler (`DLLMain`), but global objects' destructors within a DLL run within the unload handler.

As long as the main LLVM code is linked within lld.exe, the LLVM threadpool executor destructor doesn't get run (or if changing `_exit()`into `exit()`, the destructors run in a context where it is ok to clean up threads), and everything is fine. But if the threadpool code is within LLVM code built as a separate DLL, the global destructor for `static ThreadPoolExecutor exec;` does run, in `DLLMain` when unloading the DLL, where you can't do thread cleanup and the destructor subsequently hangs.

So if @ruiu is ok with the performance impact on always running this destructor when exiting lld, this change probably is fine. If not, we'd have to do something like this:

  #if defined(_WIN32) && defined(LLVM_LINK_LLVM_DYLIB) // I don't think there's a define for this?
  static llvm::ManagedStatic<ThreadPoolExecutor> exec; // This destructor can't run on DLL unload where it hangs; make sure it is called already on llvm_shutdown().
  #else
  static ThreadPoolExecutor exec;
  #endif


Repository:
  rL LLVM

https://reviews.llvm.org/D53968