net: make Server.prototype.unref() persistent#897
Closed
Uh oh!
There was an error while loading. Please reload this page.
Conversation
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
Currently, the unref() method does not remember any state if called before the server's handle has been created. This commit adds state to track calls to ref() and unref().
Contributor
evanlucas commented Feb 20, 2015
LGTM |
cjihrig added a commit that referenced this pull request Feb 21, 2015
Currently, the unref() method does not remember any state if called before the server's handle has been created. This commit adds state to track calls to ref() and unref(). PR-URL: #897 Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Brendan Ashworth <[email protected]>
Contributor
brendanashworth commented Feb 21, 2015
This was referenced Feb 23, 2015
Trott added a commit to Trott/io.js that referenced this pull request Nov 6, 2016
`test-regress-nodejsGH-897` is dependent on a timer firing within a period of time. Especially on some of the FreeBSD hosts on CI, we have seen tests like that fail when run in parallel. (This may have nothing to do with FreeBSD and may just mean that the hosts are resource-constrained.) Move this test to sequential as we have done with several other timer-dependent tests recently. The test has also been refactored and documented via comments.
Trott added a commit to Trott/io.js that referenced this pull request Nov 10, 2016
`test-regress-nodejsGH-897` is dependent on a timer firing within a period of time. Especially on some of the FreeBSD hosts on CI, we have seen tests like that fail when run in parallel. (This may have nothing to do with FreeBSD and may just mean that the hosts are resource-constrained.) Move this test to sequential as we have done with several other timer-dependent tests recently. The test has also been refactored and documented via comments. PR-URL: nodejs#9487 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Minwoo Jung <[email protected]>
addaleax pushed a commit that referenced this pull request Nov 22, 2016
`test-regress-GH-897` is dependent on a timer firing within a period of time. Especially on some of the FreeBSD hosts on CI, we have seen tests like that fail when run in parallel. (This may have nothing to do with FreeBSD and may just mean that the hosts are resource-constrained.) Move this test to sequential as we have done with several other timer-dependent tests recently. The test has also been refactored and documented via comments. PR-URL: #9487 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Minwoo Jung <[email protected]>
addaleax pushed a commit to addaleax/node that referenced this pull request Dec 8, 2016
`test-regress-nodejsGH-897` is dependent on a timer firing within a period of time. Especially on some of the FreeBSD hosts on CI, we have seen tests like that fail when run in parallel. (This may have nothing to do with FreeBSD and may just mean that the hosts are resource-constrained.) Move this test to sequential as we have done with several other timer-dependent tests recently. The test has also been refactored and documented via comments. PR-URL: nodejs#9487 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Minwoo Jung <[email protected]>
MylesBorins pushed a commit that referenced this pull request Dec 20, 2016
`test-regress-GH-897` is dependent on a timer firing within a period of time. Especially on some of the FreeBSD hosts on CI, we have seen tests like that fail when run in parallel. (This may have nothing to do with FreeBSD and may just mean that the hosts are resource-constrained.) Move this test to sequential as we have done with several other timer-dependent tests recently. The test has also been refactored and documented via comments. PR-URL: #9487 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Minwoo Jung <[email protected]>
MylesBorins pushed a commit that referenced this pull request Dec 21, 2016
`test-regress-GH-897` is dependent on a timer firing within a period of time. Especially on some of the FreeBSD hosts on CI, we have seen tests like that fail when run in parallel. (This may have nothing to do with FreeBSD and may just mean that the hosts are resource-constrained.) Move this test to sequential as we have done with several other timer-dependent tests recently. The test has also been refactored and documented via comments. PR-URL: #9487 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Minwoo Jung <[email protected]>
MylesBorins pushed a commit that referenced this pull request Dec 21, 2016
`test-regress-GH-897` is dependent on a timer firing within a period of time. Especially on some of the FreeBSD hosts on CI, we have seen tests like that fail when run in parallel. (This may have nothing to do with FreeBSD and may just mean that the hosts are resource-constrained.) Move this test to sequential as we have done with several other timer-dependent tests recently. The test has also been refactored and documented via comments. PR-URL: #9487 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Minwoo Jung <[email protected]>
Trott added a commit to Trott/io.js that referenced this pull request Jan 19, 2017
Even after being moved to `sequential` in 1ce05ad, `test-regress-nodejsGH-897` still was occasionally flaky on Raspberry Pi devices on CI. The test is especially sensitive to resource constraints. It failed reliably on my laptop if I moved it to `parallel` and ran 32 competing node test processes. Even for a flaky test, that's unusually low. I typically don't see problems, even for flaky tests, until I get up to around four times that number. On a Raspberry Pi, of course, that sensitivity to resource constraints will manifest much sooner. This change checks the order of timers firing, rather than the duration before a timer is fired. This eliminates the sensitivity to resource constraints. The test can now be moved back to `parallel`. I am able to run many copies of the test simultaneously without seeing test failures. Fixes: nodejs#10073
Trott added a commit to Trott/io.js that referenced this pull request Jan 23, 2017
Even after being moved to `sequential` in 1ce05ad, `test-regress-nodejsGH-897` still was occasionally flaky on Raspberry Pi devices on CI. The test is especially sensitive to resource constraints. It failed reliably on my laptop if I moved it to `parallel` and ran 32 competing node test processes. Even for a flaky test, that's unusually low. I typically don't see problems, even for flaky tests, until I get up to around four times that number. On a Raspberry Pi, of course, that sensitivity to resource constraints will manifest much sooner. This change checks the order of timers firing, rather than the duration before a timer is fired. This eliminates the sensitivity to resource constraints. The test can now be moved back to `parallel`. I am able to run many copies of the test simultaneously without seeing test failures. PR-URL: nodejs#10903Fixes: nodejs#10073 Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Trott added a commit to Trott/io.js that referenced this pull request Jan 23, 2017
In test-timers, confirm that all input values that should be coerced to 1 ms are not being coerced to a significantly larger value. This eliminates the need for the separate test-regress-nodejsGH-897.
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 25, 2017
Even after being moved to `sequential` in 1ce05ad, `test-regress-nodejsGH-897` still was occasionally flaky on Raspberry Pi devices on CI. The test is especially sensitive to resource constraints. It failed reliably on my laptop if I moved it to `parallel` and ran 32 competing node test processes. Even for a flaky test, that's unusually low. I typically don't see problems, even for flaky tests, until I get up to around four times that number. On a Raspberry Pi, of course, that sensitivity to resource constraints will manifest much sooner. This change checks the order of timers firing, rather than the duration before a timer is fired. This eliminates the sensitivity to resource constraints. The test can now be moved back to `parallel`. I am able to run many copies of the test simultaneously without seeing test failures. PR-URL: nodejs#10903Fixes: nodejs#10073 Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Trott added a commit that referenced this pull request Jan 26, 2017
In test-timers, confirm that all input values that should be coerced to 1 ms are not being coerced to a significantly larger value. This eliminates the need for the separate test-regress-GH-897. PR-URL: #10960 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 27, 2017
Even after being moved to `sequential` in 1ce05ad, `test-regress-nodejsGH-897` still was occasionally flaky on Raspberry Pi devices on CI. The test is especially sensitive to resource constraints. It failed reliably on my laptop if I moved it to `parallel` and ran 32 competing node test processes. Even for a flaky test, that's unusually low. I typically don't see problems, even for flaky tests, until I get up to around four times that number. On a Raspberry Pi, of course, that sensitivity to resource constraints will manifest much sooner. This change checks the order of timers firing, rather than the duration before a timer is fired. This eliminates the sensitivity to resource constraints. The test can now be moved back to `parallel`. I am able to run many copies of the test simultaneously without seeing test failures. PR-URL: nodejs#10903Fixes: nodejs#10073 Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
targos pushed a commit that referenced this pull request Jan 28, 2017
In test-timers, confirm that all input values that should be coerced to 1 ms are not being coerced to a significantly larger value. This eliminates the need for the separate test-regress-GH-897. PR-URL: #10960 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Merged
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 30, 2017
Even after being moved to `sequential` in 1ce05ad, `test-regress-nodejsGH-897` still was occasionally flaky on Raspberry Pi devices on CI. The test is especially sensitive to resource constraints. It failed reliably on my laptop if I moved it to `parallel` and ran 32 competing node test processes. Even for a flaky test, that's unusually low. I typically don't see problems, even for flaky tests, until I get up to around four times that number. On a Raspberry Pi, of course, that sensitivity to resource constraints will manifest much sooner. This change checks the order of timers firing, rather than the duration before a timer is fired. This eliminates the sensitivity to resource constraints. The test can now be moved back to `parallel`. I am able to run many copies of the test simultaneously without seeing test failures. PR-URL: nodejs#10903Fixes: nodejs#10073 Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 30, 2017
In test-timers, confirm that all input values that should be coerced to 1 ms are not being coerced to a significantly larger value. This eliminates the need for the separate test-regress-nodejsGH-897. PR-URL: nodejs#10960 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 30, 2017
Even after being moved to `sequential` in 1ce05ad, `test-regress-nodejsGH-897` still was occasionally flaky on Raspberry Pi devices on CI. The test is especially sensitive to resource constraints. It failed reliably on my laptop if I moved it to `parallel` and ran 32 competing node test processes. Even for a flaky test, that's unusually low. I typically don't see problems, even for flaky tests, until I get up to around four times that number. On a Raspberry Pi, of course, that sensitivity to resource constraints will manifest much sooner. This change checks the order of timers firing, rather than the duration before a timer is fired. This eliminates the sensitivity to resource constraints. The test can now be moved back to `parallel`. I am able to run many copies of the test simultaneously without seeing test failures. PR-URL: nodejs#10903Fixes: nodejs#10073 Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 30, 2017
In test-timers, confirm that all input values that should be coerced to 1 ms are not being coerced to a significantly larger value. This eliminates the need for the separate test-regress-nodejsGH-897. PR-URL: nodejs#10960 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
MylesBorins pushed a commit that referenced this pull request Mar 8, 2017
Even after being moved to `sequential` in 1ce05ad, `test-regress-GH-897` still was occasionally flaky on Raspberry Pi devices on CI. The test is especially sensitive to resource constraints. It failed reliably on my laptop if I moved it to `parallel` and ran 32 competing node test processes. Even for a flaky test, that's unusually low. I typically don't see problems, even for flaky tests, until I get up to around four times that number. On a Raspberry Pi, of course, that sensitivity to resource constraints will manifest much sooner. This change checks the order of timers firing, rather than the duration before a timer is fired. This eliminates the sensitivity to resource constraints. The test can now be moved back to `parallel`. I am able to run many copies of the test simultaneously without seeing test failures. PR-URL: #10903Fixes: #10073 Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
jasnell pushed a commit that referenced this pull request Mar 8, 2017
In test-timers, confirm that all input values that should be coerced to 1 ms are not being coerced to a significantly larger value. This eliminates the need for the separate test-regress-GH-897. PR-URL: #10960 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
jasnell pushed a commit that referenced this pull request Mar 8, 2017
In test-timers, confirm that all input values that should be coerced to 1 ms are not being coerced to a significantly larger value. This eliminates the need for the separate test-regress-GH-897. PR-URL: #10960 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
MylesBorins pushed a commit that referenced this pull request Mar 9, 2017
Even after being moved to `sequential` in 1ce05ad, `test-regress-GH-897` still was occasionally flaky on Raspberry Pi devices on CI. The test is especially sensitive to resource constraints. It failed reliably on my laptop if I moved it to `parallel` and ran 32 competing node test processes. Even for a flaky test, that's unusually low. I typically don't see problems, even for flaky tests, until I get up to around four times that number. On a Raspberry Pi, of course, that sensitivity to resource constraints will manifest much sooner. This change checks the order of timers firing, rather than the duration before a timer is fired. This eliminates the sensitivity to resource constraints. The test can now be moved back to `parallel`. I am able to run many copies of the test simultaneously without seeing test failures. PR-URL: #10903Fixes: #10073 Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
MylesBorins pushed a commit that referenced this pull request Mar 9, 2017
In test-timers, confirm that all input values that should be coerced to 1 ms are not being coerced to a significantly larger value. This eliminates the need for the separate test-regress-GH-897. PR-URL: #10960 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
Merged
MylesBorins pushed a commit that referenced this pull request Mar 9, 2017
In test-timers, confirm that all input values that should be coerced to 1 ms are not being coerced to a significantly larger value. This eliminates the need for the separate test-regress-GH-897. PR-URL: #10960 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]>
This was referenced Jul 8, 2023
Sign up for freeto 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.
Currently, the
unref()method does not remember any state if called before the server's handle has been created. This commit adds state to track calls toref()andunref().Related to nodejs/node-v0.x-archive#7077