-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
doc: clarify concurrency model of test runner #47642
Conversation
Review requested:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks
@@ -795,7 +801,7 @@ changes: | |||
* `options` {Object} Configuration options for the test. The following | |||
properties are supported: | |||
* `concurrency` {number|boolean} If a number is provided, | |||
then that many tests would run in parallel. | |||
then that many tests would run in parallel within the application thread. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this adds clarity?
then that many tests would run in parallel within the application thread. | |
then that many tests would run in parallel within the current thread, similar to a set of promises awaited by `Promise.allSettled`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think using current
vs application
does a great job at clarifying things. Why do you think it's important to call out Promise.allSettled
vs anything else? I don't think it's helpful, it might even be a bit confusing given that the code doesn't use Promise.allSettled
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m trying to get across that it’s “in parallel” only in the sense that there are several async resources running within the current thread and process, as opposed to “true” parallelism from using multiple threads/processes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think #47642 (review) is a better suggestion, I agree that "parallel" is simply not a great word to describe what happens here, but let's take that discussion to another PR/issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would change the word "parallel" when it's used to "concurrently" when it applies to running in the same js thread and use "parallel" exclusively to refer to cases where multiple workers are used.
Landed in a51c894 |
The documentation appears to still be wrong w.r.t. the meaning of the concurrency option of the test() function. The implementation appears to default to Infinity when the option is set to true. Is that intended or a good idea? I don't know. It certainly makes more sense than what the documentation says (which is basing the number of concurrent tasks within a single thread on the number of CPU cores). This changes the documentation to hopefully match the implementation and adds a test that rules out the (rather arbitrary) behavior described in the documentation. Refs: nodejs#47365 Refs: nodejs#47642
Refs: nodejs#47365 PR-URL: nodejs#47642 Reviewed-By: Moshe Atlow <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
Refs: nodejs#47365 PR-URL: nodejs#47642 Reviewed-By: Moshe Atlow <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
The documentation appears to still be wrong w.r.t. the meaning of the concurrency option of the test() function. The implementation appears to default to Infinity when the option is set to true. Is that intended or a good idea? I don't know. It certainly makes more sense than what the documentation says (which is basing the number of concurrent tasks within a single thread on the number of CPU cores). This changes the documentation to hopefully match the implementation and adds a test that rules out the (rather arbitrary) behavior described in the documentation. Refs: #47365 Refs: #47642 PR-URL: #47734 Reviewed-By: Moshe Atlow <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Refs: nodejs#47365 PR-URL: nodejs#47642 Reviewed-By: Moshe Atlow <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
The documentation appears to still be wrong w.r.t. the meaning of the concurrency option of the test() function. The implementation appears to default to Infinity when the option is set to true. Is that intended or a good idea? I don't know. It certainly makes more sense than what the documentation says (which is basing the number of concurrent tasks within a single thread on the number of CPU cores). This changes the documentation to hopefully match the implementation and adds a test that rules out the (rather arbitrary) behavior described in the documentation. Refs: nodejs#47365 Refs: nodejs#47642 PR-URL: nodejs#47734 Reviewed-By: Moshe Atlow <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Refs: #47365 PR-URL: #47642 Reviewed-By: Moshe Atlow <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
The documentation appears to still be wrong w.r.t. the meaning of the concurrency option of the test() function. The implementation appears to default to Infinity when the option is set to true. Is that intended or a good idea? I don't know. It certainly makes more sense than what the documentation says (which is basing the number of concurrent tasks within a single thread on the number of CPU cores). This changes the documentation to hopefully match the implementation and adds a test that rules out the (rather arbitrary) behavior described in the documentation. Refs: #47365 Refs: #47642 PR-URL: #47734 Reviewed-By: Moshe Atlow <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
The documentation appears to still be wrong w.r.t. the meaning of the concurrency option of the test() function. The implementation appears to default to Infinity when the option is set to true. Is that intended or a good idea? I don't know. It certainly makes more sense than what the documentation says (which is basing the number of concurrent tasks within a single thread on the number of CPU cores). This changes the documentation to hopefully match the implementation and adds a test that rules out the (rather arbitrary) behavior described in the documentation. Refs: #47365 Refs: #47642 PR-URL: #47734 Reviewed-By: Moshe Atlow <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Refs: #47365 PR-URL: #47642 Reviewed-By: Moshe Atlow <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
The documentation appears to still be wrong w.r.t. the meaning of the concurrency option of the test() function. The implementation appears to default to Infinity when the option is set to true. Is that intended or a good idea? I don't know. It certainly makes more sense than what the documentation says (which is basing the number of concurrent tasks within a single thread on the number of CPU cores). This changes the documentation to hopefully match the implementation and adds a test that rules out the (rather arbitrary) behavior described in the documentation. Refs: #47365 Refs: #47642 PR-URL: #47734 Reviewed-By: Moshe Atlow <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Refs: nodejs#47365 PR-URL: nodejs#47642 Reviewed-By: Moshe Atlow <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: James M Snell <[email protected]>
The documentation appears to still be wrong w.r.t. the meaning of the concurrency option of the test() function. The implementation appears to default to Infinity when the option is set to true. Is that intended or a good idea? I don't know. It certainly makes more sense than what the documentation says (which is basing the number of concurrent tasks within a single thread on the number of CPU cores). This changes the documentation to hopefully match the implementation and adds a test that rules out the (rather arbitrary) behavior described in the documentation. Refs: nodejs#47365 Refs: nodejs#47642 PR-URL: nodejs#47734 Reviewed-By: Moshe Atlow <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
This is based on my understanding of how it works, but I didn't actually test this or compare it with the implementation, so please review carefully @nodejs/test_runner.
Refs: #47365