Fix Bun 1.4 + pthreads by always bridging parentPort in worker threads - #27582
Open
sbc100 wants to merge 1 commit into
Open
Fix Bun 1.4 + pthreads by always bridging parentPort in worker threads#27582sbc100 wants to merge 1 commit into
parentPort in worker threads#27582sbc100 wants to merge 1 commit into
Conversation
dschuff
reviewed
Aug 21, 2026
| var worker_threads = await import('node:worker_threads'); | ||
| globalThis.Worker = worker_threads.Worker; | ||
| var parentPort = worker_threads.parentPort; | ||
| // Deno and Bun already have `postMessage` defined on the global scope and |
Member
There was a problem hiding this comment.
so this isn't a problem for deno?
Collaborator
Author
There was a problem hiding this comment.
It seems not no.
Sadly this change does beak bun < 1.4 (since it ends up delivering messages twice).. but I'm not sure we care about back compat at this point.
Collaborator
There was a problem hiding this comment.
It seems like the original reason for the guard was fixed in denoland/deno#32596.
sbc100
force-pushed
the
fix_bun_pthreads
branch
from
August 22, 2026 01:09
2396aa6 to
a6bb266
Compare
In emscripten-core#25947, a check for `!globalThis.postMessage` was added before wiring `parentPort.on('message') -> globalThis.onmessage` and `globalThis.postMessage = (msg) => parentPort.postMessage(msg)`. However, in Bun 1.4+, `node:worker_threads` deliveries are isolated to `parentPort` (they are no longer automatically routed to `globalThis.onmessage`), while `globalThis.postMessage` remains defined on the global object. Because `globalThis.postMessage` was truthy, Emscripten skipped hooking `parentPort.on('message')`, leaving worker threads unresponsive to initialization messages from the main thread. Removing the `if (!globalThis.postMessage)` guard ensures `parentPort` is always correctly wired whenever running in a Node-style worker thread. Fixes: emscripten-core#27580
sbc100
force-pushed
the
fix_bun_pthreads
branch
from
August 22, 2026 01:15
a6bb266 to
cc426e2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In #25947, a check for
!globalThis.postMessagewas added before wiringparentPort.on('message') -> globalThis.onmessageandglobalThis.postMessage = (msg) => parentPort.postMessage(msg).However, in Bun 1.4+,
node:worker_threadsdeliveries are isolated toparentPort(they are no longer automatically routed toglobalThis.onmessage), whileglobalThis.postMessageremains defined on the global object. BecauseglobalThis.postMessagewas truthy, Emscripten skipped hookingparentPort.on('message'), leaving worker threads unresponsive to initialization messages from the main thread.Removing the
if (!globalThis.postMessage)guard ensuresparentPortis always correctly wired whenever running in a Node-style worker thread.Fixes: #27580