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: use special message as MessagePort close command #27705

Closed
wants to merge 3 commits into from

Conversation

addaleax
Copy link
Member

(The first commit is cleanup from #27294, with which this is going to have conflicts anyway…)

When a MessagePort connected to another MessagePort closes, the
latter MessagePort will be closed as well. Until now, this is done
by testing whether the ports are still entangled after processing
messages. This leaves open a race condition window in which messages
sent just before the closure can be lost when timing is unfortunate.
(A description of the timing is in the test file.)

This can be addressed by using a special message instead, which is
the last message received by a MessagePort. This way, all previously
sent messages are processed first.

Fixes: #22762

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

addaleax added 3 commits May 15, 2019 00:58
This is a property of the native object associated with the
`MessagePort`, not something that should be set on the
conceptual `MessagePort` that may be transferred around.
When a `MessagePort` connected to another `MessagePort` closes, the
latter `MessagePort` will be closed as well. Until now, this is done
by testing whether the ports are still entangled after processing
messages. This leaves open a race condition window in which messages
sent just before the closure can be lost when timing is unfortunate.
(A description of the timing is in the test file.)

This can be addressed by using a special message instead, which is
the last message received by a `MessagePort`. This way, all previously
sent messages are processed first.

Fixes: nodejs#22762
These tests should be fixed now.
@addaleax addaleax added the worker Issues and PRs related to Worker support. label May 14, 2019
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot nodejs-github-bot added the c++ Issues and PRs that require attention from people who are familiar with C++. label May 14, 2019
@nodejs-github-bot
Copy link
Collaborator

@addaleax
Copy link
Member Author

Landed in 9375088...6f55c53

@addaleax addaleax closed this May 17, 2019
@addaleax addaleax deleted the fix-worker-mp-flakiness branch May 17, 2019 12:02
addaleax added a commit that referenced this pull request May 17, 2019
This is a property of the native object associated with the
`MessagePort`, not something that should be set on the
conceptual `MessagePort` that may be transferred around.

PR-URL: #27705
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
addaleax added a commit that referenced this pull request May 17, 2019
When a `MessagePort` connected to another `MessagePort` closes, the
latter `MessagePort` will be closed as well. Until now, this is done
by testing whether the ports are still entangled after processing
messages. This leaves open a race condition window in which messages
sent just before the closure can be lost when timing is unfortunate.
(A description of the timing is in the test file.)

This can be addressed by using a special message instead, which is
the last message received by a `MessagePort`. This way, all previously
sent messages are processed first.

Fixes: #22762
PR-URL: #27705
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
addaleax added a commit that referenced this pull request May 17, 2019
These tests should be fixed now.

PR-URL: #27705
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
targos pushed a commit that referenced this pull request May 18, 2019
This is a property of the native object associated with the
`MessagePort`, not something that should be set on the
conceptual `MessagePort` that may be transferred around.

PR-URL: #27705
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
targos pushed a commit that referenced this pull request May 18, 2019
When a `MessagePort` connected to another `MessagePort` closes, the
latter `MessagePort` will be closed as well. Until now, this is done
by testing whether the ports are still entangled after processing
messages. This leaves open a race condition window in which messages
sent just before the closure can be lost when timing is unfortunate.
(A description of the timing is in the test file.)

This can be addressed by using a special message instead, which is
the last message received by a `MessagePort`. This way, all previously
sent messages are processed first.

Fixes: #22762
PR-URL: #27705
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
targos pushed a commit that referenced this pull request May 18, 2019
These tests should be fixed now.

PR-URL: #27705
Reviewed-By: Rich Trott <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
@BridgeAR BridgeAR mentioned this pull request May 21, 2019
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. worker Issues and PRs related to Worker support.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Investigate flaky test-worker-syntax-error-file
4 participants