Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

worker: skip main thread when stdio is inherited #47036

Closed
wants to merge 1 commit into from

Conversation

aduh95
Copy link
Contributor

@aduh95 aduh95 commented Mar 10, 2023

Currently, when the main thread is blocked, the console.log calls from the worker are swallowed.
In #25630, @jasnell and @addaleax seems to think the current behavior is correct, but I have to side with @devsnek on this, I think we can do better. Here's my (naive) attempt at this. There are some broken tests with this PR, but I would like to hear more from @nodejs/workers before spending more time on this, in case there are good reasons to disregard this approach.

Fixes: #25630

@nodejs-github-bot nodejs-github-bot added needs-ci PRs that need a full CI run. worker Issues and PRs related to Worker support. labels Mar 10, 2023
if (directStdout) {
process.stdout._writev = function _writev(chunks, cb) {
const { chunk, encoding } = ArrayPrototypePop(chunks);
write(1, chunk, { __proto__: null }, encoding, (err) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This won't work on Windows with non-ASCII text, unfortunately

Copy link
Contributor Author

@aduh95 aduh95 Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a bummer. Do we know where does this limitation come from? EDIT: seems that it's explained in #24550.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would love to land this PR. Is this non-ASCII thing an issue that needs resolution beyond just documenting as a known limitation?

Assuming that it is, could we use whatever solution console.log itself uses for outputting to stdout for Windows?

@addaleax
Copy link
Member

@addaleax seems to think the current behavior is correct, but I have to side with @devsnek on this, I think we can do better.

Just to say it explicitly because the wording above might give a different impression: These statements aren't mutually exclusive and I support both of them.

Fwiw, #30491 is another issue about this problem and contains a bit more context, also in terms of potential solutions (that may be hard to implement if they are intended to be correct).

@GeoffreyBooth
Copy link
Member

cc @nodejs/loaders since relevant to #44710

@JakobJingleheimer
Copy link
Contributor

When Antoine and I were pairing a few weeks ago, this came up, and I suggested for Windows only, check whether the output is non-ASCII and then whether whatever Windows needs has been set; if not, warn/throw. The check itself is expensive, so other platforms shouldn't suffer for the one; but the hit on Windows seems a far better alternative that unintelligible output.

@aduh95
Copy link
Contributor Author

aduh95 commented Apr 13, 2023

FWIW I tried experimenting with Jacob's idea, but didn't get very far with it, it feels wrong to have a Windows-specific code path when the issue is not Windows specific (it's only the Windows default behavior that is weird with non-ASCII data, but there are known workaround, but AFAIK there's no way for the Node.js process to know wether such workaround is in place for the system it's running on). It's probably going to be harder to document and create weird race conditions for users to have two completely different calls depending if the code is running on a Windows or a non-Windows host.

Maybe a better way of doing this would be to have an env variable to opt-in to that behavior, since the problem is environment specific.

@aduh95 aduh95 added the stalled Issues and PRs that are stalled. label Sep 20, 2023
@github-actions
Copy link
Contributor

This issue/PR was marked as stalled, it will be automatically closed in 30 days. If it should remain open, please leave a comment explaining why it should remain open.

Copy link
Contributor

Closing this because it has stalled. Feel free to reopen if this issue/PR is still relevant, or to ping the collaborator who labelled it stalled if you have any questions.

@github-actions github-actions bot closed this Nov 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-ci PRs that need a full CI run. stalled Issues and PRs that are stalled. worker Issues and PRs related to Worker support.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

worker_threads: worker.postMessage does not get executed without exiting synchronous call stack
5 participants