-
Notifications
You must be signed in to change notification settings - Fork 30k
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
lib,src: replace all C++ promises with JS promises #20830
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -113,7 +113,6 @@ const { isArrayBufferView } = require('internal/util/types'); | |
const { FileHandle } = process.binding('fs'); | ||
const binding = process.binding('http2'); | ||
const { ShutdownWrap } = process.binding('stream_wrap'); | ||
const { createPromise, promiseResolve } = process.binding('util'); | ||
const { UV_EOF } = process.binding('uv'); | ||
|
||
const { StreamPipe } = internalBinding('stream_pipe'); | ||
|
@@ -2747,11 +2746,9 @@ function connect(authority, options, listener) { | |
// Support util.promisify | ||
Object.defineProperty(connect, promisify.custom, { | ||
value: (authority, options) => { | ||
const promise = createPromise(); | ||
const server = connect(authority, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, it seems we might be able to remove the custom promisifier entirely: what the getter is doing right now should be the exact things done by There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A test fails if that part is removed. |
||
options, | ||
() => promiseResolve(promise, server)); | ||
return promise; | ||
return new Promise((resolve) => { | ||
const server = connect(authority, options, () => resolve(server)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This changes existing behavior - if an invalid URL is passed as an authority here then the function throws. The old behavior was to throw synchronously but the new behavior throws asynchronously. In my opinion the new behavior is a behavior is better - but it's a change in error messages though. I'm not sure how it can be resolved in the promise constructor or done without reverting the change. What do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I could rewrite it to behave the same as before when doing: let callback;
const server = connect(authority, options, () => callback(server));
return new Promise((resolve) => {
callback = resolve;
}); However, I do think it is best to handle it async. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Honestly I think it's best to handle it async too but I'm not sure I get to make that call. Pinging previous approvers for more OKs - @addaleax @bmeurer @TimothyGu @devsnek - please 👍 this comment to agree to landing this (arguably bugfix) behaviour change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is a breaking change – otherwise no strong opinions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @addaleax I do not see how someone would really rely on this. Most people will probably not wrap a promise call in a try catch. So it'll end up as uncaught exception and that will likely end the process. That is not really something that anyone would want. What scenario do you see that would break with this change? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a change in experimental http2 code. There no reason to make it semver-major on the basis of this one change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, right, http2 is still experimental. Fine with me then. :) (I had originally added the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I did not realize http2 is still experimental either - I'm fine with semver-patch :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Backporting is easier as well and users get the better behavior earlier :-) (even though that only makes sense for 10.). I do not have a strong opinion on it though. If you want, I can change the timers and the child_process to behave exactly as before but I personally still believe this is a bug fix as it was never meant to behave like that (and it only did that in the first place because of the special implementation before). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @BridgeAR IIUC @addaleax is fine landing this as semver patch #20830 (comment) and later added:
Which means that this is fine to land as semver patch and on v10.x |
||
}); | ||
} | ||
}); | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -41,7 +41,6 @@ const { | |
validateTimerDuration | ||
} = require('internal/timers'); | ||
const internalUtil = require('internal/util'); | ||
const { createPromise, promiseResolve } = process.binding('util'); | ||
const util = require('util'); | ||
const { ERR_INVALID_CALLBACK } = require('internal/errors').codes; | ||
const debug = util.debuglog('timer'); | ||
|
@@ -439,11 +438,9 @@ function setTimeout(callback, after, arg1, arg2, arg3) { | |
} | ||
|
||
setTimeout[internalUtil.promisify.custom] = function(after, value) { | ||
const promise = createPromise(); | ||
const timeout = new Timeout(promise, after, [value], false); | ||
active(timeout); | ||
|
||
return promise; | ||
return new Promise((resolve) => { | ||
active(new Timeout(resolve, after, [value], false)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @apapirovski PTAL. |
||
}); | ||
}; | ||
|
||
exports.setTimeout = setTimeout; | ||
|
@@ -452,7 +449,7 @@ exports.setTimeout = setTimeout; | |
function ontimeout(timer) { | ||
const args = timer._timerArgs; | ||
if (typeof timer._onTimeout !== 'function') | ||
return promiseResolve(timer._onTimeout, args[0]); | ||
return Promise.resolve(timer._onTimeout, args[0]); | ||
if (!args) | ||
timer._onTimeout(); | ||
else | ||
|
@@ -659,7 +656,7 @@ function tryOnImmediate(immediate, oldTail, count, refCount) { | |
function runCallback(timer) { | ||
const argv = timer._argv; | ||
if (typeof timer._onImmediate !== 'function') | ||
return promiseResolve(timer._onImmediate, argv[0]); | ||
return Promise.resolve(timer._onImmediate, argv[0]); | ||
if (!argv) | ||
return timer._onImmediate(); | ||
Reflect.apply(timer._onImmediate, timer, argv); | ||
|
@@ -738,9 +735,7 @@ function setImmediate(callback, arg1, arg2, arg3) { | |
} | ||
|
||
setImmediate[internalUtil.promisify.custom] = function(value) { | ||
const promise = createPromise(); | ||
new Immediate(promise, [value]); | ||
return promise; | ||
return new Promise((resolve) => new Immediate(resolve, [value])); | ||
}; | ||
|
||
exports.setImmediate = setImmediate; | ||
|
This file was deleted.
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.
It was written that way to avoid allocation of a closure and be speed-competitive with bluebird.
I’d like to make sure that the speed remains as fast
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.
Yes, we should measure the performance here.
I was suggesting to start with JS promises instead, since we spend some time recently to even inline the promise constructor into TurboFan optimized code. If that turns out to be too slow, then the other alternative is to use the createPromise and friends from
v8-extras
, which is also known to TurboFan, and significantly faster than going through C++.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.
+1 for createPromise from v8-extras.