Deprecate domains #75

tellnes · 2014-12-05T04:00:55Z

Also, I did notice that domain.dispose() is deprecated but missing a deprecation message. So it includes a commit which fixes it. Please inform me if you want it as a separate pull request.

I've also changed two test assertions. I belive usage of domain in lib/repl.js was swallowing the assert errors and that those are currently broken.

bnoordhuis · 2014-12-05T21:14:40Z

lib/domain.js

@@ -290,4 +290,5 @@ Domain.prototype.dispose = util.deprecate(function() {
  // mark this domain as 'no longer relevant'
  // so that it can't be entered or activated.
  this._disposed = true;
-});
+}, 'domain.dispose() is deprecated. Please recover from failed IO actions ' +
+    'explicitly via error event handlers set on the domain.');


Is this the advice we want to give?

It is copied directly from the documentation in doc/api/domain.markdown (d86814a)

Ah, good catch. Can you amend the commit log to mention that?

EDIT: On a general note, commit logs should explain what changed and why. One-liners are almost never sufficient.

I've added some more info to the commit message.

bnoordhuis · 2014-12-05T23:04:26Z

The PR mostly LGTM. The commit logs could perhaps still use some love and it would be good to have closure on the failing test but the basic approach seems sound.

I'd like to get one more LGTM. @chrisdickinson or @cjihrig Can one of you take a look?

othiym23 · 2014-12-05T23:12:09Z

lib/repl.js

+    return true;
+  }
+}
+var asyncListener = tracing.createAsyncListener({ error: errorListener });


I thought that tracing.createAsyncListener() was going away as part of @trevnorris's work on removing the JS-side AsyncListener API. Am I incorrect?

In that case, what is the correct api to use?

The safest thing would be to stick with domains for now, perhaps with a workaround to allow the REPL to use them without printing a deprecation warning. If you felt ambitious, you might build a lightweight layer atop the C++ AsyncWrap implementation (which will still be exposed via process.binding). But since domains are just getting deprecated, not removed, it's fine to still be using them in core, in my opinion. @trevnorris, do you have thoughts on this?

What about some code for the repl in process._fatalException in src/node.js?

Alternatively we can just listen to uncaughtException. This functionality is about not breaking the repl when there is an uncaughtException and instead just displaying the error to the user.

I would lean more towards using process._fatalException than uncaughtException, because the latter is built on the former anyway. I'm sure a decent top-level error handler could be built atop _fatalException alone, but, out of curiosity: why not just leave the domains code in the REPL for now? It works fine in the repl, the domains code will still be there for a while, and as far as I know, many people near to core are still committed to the idea of coming up with an improved async error-handling solution for Node in the not too distant future.

All the domain code is still in the REPL. I've just changed it to only use domains if the user provides one (which is possible, but undocumented). It does not fallback to calling domain.create() which trigger the deprecation warning.

Actually, how it is implemented now makes the REPL catch all uncaught exceptions. Maybe that should be possible to change with an option and be disabled by default if you are using the REPL as a library.

I think this is getting out of scope for this pull request. Maybe it should be addressed in its own? But it needs to be addressed before the deprecation can be merged.

tellnes · 2014-12-06T02:04:01Z

About the test I've changed.

After some digging I've found out it actually was broken by 7afdba6.

I've changed the test to look like the following code. This fails on the current v0.12 branch which proves the error was swallowed.

testMe.complete('toSt', function(error, data) {
  try {
    assert.deepEqual(data, [['toString'], 'toSt']);
  } catch (err) {
    console.log('error');
    process.exit(1);
    return;
  }
  console.log('ok');
});

chrisdickinson · 2014-12-06T08:40:18Z

lib/repl.js

+  if (!exports.repl) {
+    exports.repl = repl;
+    tracing.addAsyncListener(asyncListener);
+    repl.on('exit', function() {


This is just me being paranoid, but could we use .once here?

Sure, but shouldn't that be guaranteed by the api that the exit code is only fired once? If not, there probably a lot of broken code out there.

One reason to prefer .once() over .on() is that the former lets the function's closure object get garbage collected before the EventEmitter object is collected.

Ok, I'll change it.

tellnes · 2014-12-07T16:57:29Z

Ok. I've removed the REPL changes and just fixed it so it doesn't shows a deprecation warning. I think the REPL issues should be addressed on its own.

I'll wait until @trevnorris or some one else comments on the usage of tracing.createAsyncListener() before I'd do something more about the REPL.

caineio · 2014-12-08T15:18:55Z

Hello!

I am pleased to see your valuable contribution to this project. Would you
please mind answering a couple of questions to help me classify this submission
and/or gather required information for the core team members?

Questions:

Which part of core do you think it might be related to?
One of: debugger, http, assert, buffer, child_process, cluster, crypto, dgram, dns, domain, events, fs, http, https, module, net, os, path, querystring, readline, repl, smalloc, stream, timers, tls, url, util, vm, zlib, c++, docs, other (label)
Which versions of io.js do you think are affected by this?
One of: v0.10, v0.12, v1.0.0 (label)
PR-only Does make test pass after applying this Pull Request.
Expected: yes
PR-only Is the commit message properly formatted? (See
CONTRIBUTING.md for more information)
Expected: yes

Please provide the answers in an ordered list like this:

Answer for the first question
Answer for the second question
...

Note that I am just a bot with a limited human-reply parsing abilities,
so please be very careful with numbers and don't skip the questions!

In case of success I will say: ...summoning the core team devs!.

In case of validation problem I will say: Sorry, but something is not right here:.

Truly yours,
Caine.

Responsibilities

indutny: crypto, tls, https, child_process, c++
trevnorris: buffer, http, https, smalloc
bnoordhuis: http, cluster, child_process, dgram

tellnes · 2014-12-08T16:08:50Z

domain
v0.12
yes
yes

caineio · 2014-12-08T16:08:53Z

...summoning the core team devs!

bnoordhuis · 2014-12-09T17:16:09Z

Ping @chrisdickinson, @cjihrig and @trevnorris. I'll bring this up in the TC meeting tomorrow and I'm assigning it to the v1.0.0 milestone so that we will have to make a decision before the first release.

cjihrig · 2014-12-09T18:07:05Z

test/simple/test-repl-no-deprecation-messages.js

+
+child.stderr.setEncoding('utf8');
+child.stderr.on('data', function (chunk) {
+  stderr += chunk;


You can just fail here and remove the child.on('exit', ...);

cjihrig · 2014-12-09T18:12:17Z

This LGTM besides one nit.

I'm in favor of deprecating domains, but has an replacement been discussed? For example, I've heard of (but not looked into whatsoever) StrongLoop's zones. Or, is the idea going forward not to have a replacement?

Deprecated in d86814a without a deprecation message. Deprecation message copied from documentation.

Original commit message: [LTS-M86][compiler][x64] Fix bug in InstructionSelector::ChangeInt32ToInt64 (cherry picked from commit 02f84c745fc0cae5927a66dc4a3e81334e8f60a6) No-Try: true No-Presubmit: true No-Tree-Checks: true Bug: chromium:1196683 Change-Id: Ib4ea738b47b64edc81450583be4c80a41698c3d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2820971 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#73903} Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2821959 Commit-Queue: Jana Grill <janagrill@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Victor-Gabriel Savu <vsavu@google.com> Cr-Commit-Position: refs/branch-heads/8.6@{nodejs#75} Cr-Branched-From: a64aed2333abf49e494d2a5ce24bbd14fff19f60-refs/heads/8.6.395@{#1} Cr-Branched-From: a626bc036236c9bf92ac7b87dc40c9e538b087e3-refs/heads/master@{#69472} Refs: v8/v8@3066b7b

Original commit message: [LTS-M86][compiler][x64] Fix bug in InstructionSelector::ChangeInt32ToInt64 (cherry picked from commit 02f84c745fc0cae5927a66dc4a3e81334e8f60a6) No-Try: true No-Presubmit: true No-Tree-Checks: true Bug: chromium:1196683 Change-Id: Ib4ea738b47b64edc81450583be4c80a41698c3d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2820971 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#73903} Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2821959 Commit-Queue: Jana Grill <janagrill@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Victor-Gabriel Savu <vsavu@google.com> Cr-Commit-Position: refs/branch-heads/8.6@{#75} Cr-Branched-From: a64aed2333abf49e494d2a5ce24bbd14fff19f60-refs/heads/8.6.395@{#1} Cr-Branched-From: a626bc036236c9bf92ac7b87dc40c9e538b087e3-refs/heads/master@{#69472} Refs: v8/v8@3066b7b PR-URL: #38275 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com>

tellnes mentioned this pull request Dec 5, 2014

deprecate domains #66

Closed

bnoordhuis reviewed Dec 5, 2014
View reviewed changes

tellnes force-pushed the domain branch 2 times, most recently from 53ed3ec to 6805268 Compare December 5, 2014 21:40

othiym23 reviewed Dec 5, 2014
View reviewed changes

chrisdickinson reviewed Dec 6, 2014
View reviewed changes

tellnes force-pushed the domain branch from 6805268 to 68326b9 Compare December 7, 2014 16:49

caineio added needs info and removed needs info labels Dec 8, 2014

caineio added v0.12 domain Issues and PRs related to the domain subsystem. and removed need info labels Dec 8, 2014

bnoordhuis added this to the v1.0.0 milestone Dec 9, 2014

cjihrig reviewed Dec 9, 2014
View reviewed changes

domain: add deprecation message for domain.dispose

7a6ceb7

Deprecated in d86814a without a deprecation message. Deprecation message copied from documentation.

joyeecheung mentioned this pull request Feb 20, 2020

repl: printing big strings results in OOM #25478

Closed

snyk-bot mentioned this pull request May 5, 2020

[Snyk] Upgrade remark-preset-lint-node from 1.13.0 to 1.15.0 137717unity/node#4

Open

wmertens mentioned this pull request Jun 19, 2020

uv__io_stop: Assertion `loop->watchers[w->fd] == w' failed. #33966

Closed

snyk-bot mentioned this pull request Sep 1, 2021

[Snyk] Security upgrade libnpx from 9.7.1 to 10.0.0 KamilPolivka/node#19

Open

solebox mentioned this pull request May 13, 2022

[Snyk] Fix for 1 vulnerabilities solebox/node#29

Open

enterstudio mentioned this pull request May 14, 2022

[Snyk] Fix for 1 vulnerabilities enterstudio/node#28

Open

UbuntuEvangelist mentioned this pull request May 14, 2022

[Snyk] Fix for 1 vulnerabilities UbuntuEvangelist/node#22

Open

s4sc mentioned this pull request May 14, 2022

[Snyk] Fix for 1 vulnerabilities s4sc/node#28

Open

snyk-bot mentioned this pull request Jan 8, 2023

[Snyk] Upgrade @humanwhocodes/config-array from 0.9.5 to 0.11.8 AshdonG/node#3

Open

Bhanditz mentioned this pull request Nov 26, 2023

[Snyk] Fix for 2 vulnerabilities Bhanditz/node#34

Open

bumplzz69 mentioned this pull request Nov 26, 2023

[Snyk] Fix for 2 vulnerabilities bumplzz69/node#54

Open

RoeeOren mentioned this pull request Nov 27, 2023

[Snyk] Fix for 2 vulnerabilities RoeeOren/node#41

Open

bsmoove247 mentioned this pull request Nov 27, 2023

[Snyk] Fix for 1 vulnerabilities bsmoove247/node#62

Open

Verdinjoshua26 mentioned this pull request Nov 27, 2023

[Snyk] Fix for 1 vulnerabilities Verdinjoshua26/node#49

Open

Matthelonianxl mentioned this pull request Nov 27, 2023

[Snyk] Fix for 1 vulnerabilities Matthelonianxl/node#56

Open

sirinartk mentioned this pull request Nov 28, 2023

[Snyk] Fix for 1 vulnerabilities sirinartk/node#46

Open

timzwit mentioned this pull request Nov 28, 2023

[Snyk] Fix for 2 vulnerabilities timzwit/node#30

Open

vaibhavb mentioned this pull request Nov 28, 2023

[Snyk] Fix for 2 vulnerabilities vaibhavb/node#43

Open

awaisab172 mentioned this pull request Nov 29, 2023

[Snyk] Fix for 1 vulnerabilities awaisab172/node#49

Open

ajesse11x mentioned this pull request Nov 29, 2023

[Snyk] Fix for 2 vulnerabilities ajesse11x/node#44

Open

This was referenced Dec 1, 2023

[Snyk] Security upgrade pkg from 4.3.4 to 4.4.3 MaxMood96/node#38

Open

[Snyk] Security upgrade pkg from 4.3.4 to 4.4.3 Mement-Mori/node#33

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Deprecate domains #75

Deprecate domains #75

tellnes commented Dec 5, 2014

bnoordhuis Dec 5, 2014

tellnes Dec 5, 2014

bnoordhuis Dec 5, 2014

tellnes Dec 5, 2014

bnoordhuis commented Dec 5, 2014

othiym23 Dec 5, 2014

tellnes Dec 6, 2014

othiym23 Dec 6, 2014

tellnes Dec 6, 2014

othiym23 Dec 6, 2014

tellnes Dec 6, 2014

tellnes Dec 6, 2014

tellnes commented Dec 6, 2014

chrisdickinson Dec 6, 2014

tellnes Dec 6, 2014

bnoordhuis Dec 7, 2014

tellnes Dec 7, 2014

tellnes commented Dec 7, 2014

caineio commented Dec 8, 2014

tellnes commented Dec 8, 2014

caineio commented Dec 8, 2014

bnoordhuis commented Dec 9, 2014

cjihrig Dec 9, 2014

cjihrig commented Dec 9, 2014

Deprecate domains #75

Deprecate domains #75

Conversation

tellnes commented Dec 5, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bnoordhuis commented Dec 5, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tellnes commented Dec 6, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tellnes commented Dec 7, 2014

caineio commented Dec 8, 2014

Questions:

Responsibilities

tellnes commented Dec 8, 2014

caineio commented Dec 8, 2014

bnoordhuis commented Dec 9, 2014

Choose a reason for hiding this comment

cjihrig commented Dec 9, 2014