Fix macros which call Bun.file operations causing build commands to hang

[brainkim]

What does this PR do?

• Documentation or TypeScript types (it's okay to leave the rest blank in this case)
• Code changes

Users reported in #7611 and #14104 that calling Bun.file().text() in a macro would cause builds to hang. This bug was introduced in v1.0.16, likely when some changes related to how Bun handles multithreading occurred.

I went through a minimal reproduction with a debugger and determined that work would get stuck in ThreadPool threads because the ThreadPool was initialized twice. The double instantiation of ThreadPool, which is assumed to be a global singleton, caused issues in macros because file I/O would get scheduled on a thread, the work would be pushed to the thread local queue/buffer, and then the thread would wait for the promise to resolve, causing a dead lock. There is code which allows for “work stealing” but threads initialized from different thread pools do not steal work each other.

The least invasive fix I found was to consistently call WorkPool.get() in the bundle_v2’s initialization code.

Fixes #7611 and fixes #14104.
Happy holidays!

How did you verify your code works?

• I included a test for the new code, or existing tests cover it
• I ran my tests locally and they pass (bun-debug test test-file-name.test)

[brainkim]

I guess things are never this easy...

[Jarred-Sumner]

My guess is that by not using the bundler’s threadpool, the threads never call their init function

it sounds like we should have a global variable for “threadpool ID” and only use the global one in that case maybe?

[brainkim]

I tried building on ubuntu and the failing test passes locally. I also tested it by hand.

Is it possible that the CI is running the tests against a stale build? I’m not sure how this failure could be platform dependent. Perhaps it is due to the number of threads available?

Running the build process in a container takes a painfully long time, wishing for cross-compilation here.