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

lib: refactor some internal/* code #12644

Closed
wants to merge 5 commits into from

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented Apr 25, 2017

This one is a bit of a grab bag containing a number of small edits to a number of internal/* modules that I have been accumulating. They generally are around code cleanup or modernization

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

internal: process, module, streams, lib, fs, freelist

@nodejs-github-bot nodejs-github-bot added fs Issues and PRs related to the fs subsystem / file system. http Issues or PRs related to the http subsystem. lib / src Issues and PRs related to general changes in the lib or src directory. module Issues and PRs related to the module subsystem. process Issues and PRs related to the process subsystem. labels Apr 25, 2017
@@ -4,16 +4,17 @@ const Buffer = require('buffer').Buffer;
const Writable = require('stream').Writable;
const fs = require('fs');
const util = require('util');
const constants = process.binding('constants').fs;

const O_APPEND = constants.O_APPEND | 0;
Copy link
Contributor

@mscdex mscdex Apr 25, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might want to check if the implicit coercion to a 32-bit value was intentional (e.g. performance related or the values were not originally numbers for some reason)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I explored that a bit a couldn't find anything specific. I could be wrong, but I think the switch was more defensive just in case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also converts to an integer if it was a float, or some other type of number-ish.

@@ -2,71 +2,71 @@

const Buffer = require('buffer').Buffer;

module.exports = BufferList;
module.exports = class BufferList {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you benchmark this change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, negligible difference in master with 5.7. Notable improvement under TF-I ... tho I'd have to pull the numbers back up. It was a week or so ago when I ran it.

function setupNextTick() {
const promises = require('internal/process/promises');
const errors = require('internal/errors');
const emitPendingUnhandledRejections = promises.setup(scheduleMicrotasks);
const emitPendingUnhandledRejections = promises(scheduleMicrotasks);
Copy link
Contributor

@mscdex mscdex Apr 25, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know the other 'setup' instances had the benefit of not having to be assigned to a variable first, but perhaps we should at least change the variable name here to something more straight-forward, like setupPromises instead of just promises?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me..

_process.setupKillAndExit();
_process.setupSignalHandlers();
if (global.__coverage__)
NativeModule.require('internal/process/write-coverage').setup();
NativeModule.require('internal/process/write-coverage')();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: I used this naming convention for consistency with the other setup functions.

IMO, it would be better to preserve it for clarity.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these are already different from the other ones tho and we eliminate an extraneous property lookup. I'm not going to fight for it, but I don't see much value in keeping the separate setup() functions.

@@ -130,3 +121,12 @@ function addBuiltinLibsToObject(object) {
});
});
}

module.exports = exports = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove exports?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's my preference but in a separate issue @sam-github expressed a preference for these to retain the = exports

Copy link
Contributor

@Fishrock123 Fishrock123 Apr 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? There is no point. Since you are already exposing the variable name to grab it this way exports is defunct. (Edit: because You can just access the variable anyways)

If necessary, we can remove this in another PR entirely but idk why we'd add more here...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also agree that re-assigning exports is unnecessary. *shrug*

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm perfectly happy with removing it.

@@ -267,3 +257,14 @@ function setupRawDebug() {
rawDebug(format.apply(null, arguments));
};
}

module.exports = exports = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto?

@jasnell
Copy link
Member Author

jasnell commented Apr 27, 2017

@Fishrock123 ... ok, I dropped the commit that altered the naming conventions on the process setup items. PTAL

@Fishrock123
Copy link
Contributor

Replied to the comment about module.exports = exports.

@jasnell
Copy link
Member Author

jasnell commented Apr 27, 2017

Updated to remove the module.exports = exports =

@jasnell
Copy link
Member Author

jasnell commented Apr 27, 2017

@@ -130,3 +121,12 @@ function addBuiltinLibsToObject(object) {
});
});
}

module.exports = {
Copy link
Contributor

@mscdex mscdex Apr 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I just realized we do need exports re-assigned here in this file because exports.requireDepth is modified in this module and lib/module.js checks this value.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

heh... doh!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that particular bit could likely be refactored but I'll just replace the = exports = here for now

@jasnell
Copy link
Member Author

jasnell commented Apr 27, 2017

@jasnell
Copy link
Member Author

jasnell commented Apr 27, 2017

CI is green

@mscdex
Copy link
Contributor

mscdex commented Apr 27, 2017

LGTM

@jasnell
Copy link
Member Author

jasnell commented Apr 27, 2017

@Fishrock123 ... does this LGTY?

@jasnell
Copy link
Member Author

jasnell commented Apr 28, 2017

Will land this by monday if there are no further objections

jasnell added a commit that referenced this pull request May 1, 2017
jasnell added a commit that referenced this pull request May 1, 2017
jasnell added a commit that referenced this pull request May 1, 2017
jasnell added a commit that referenced this pull request May 1, 2017
PR-URL: #12644
Reviewed-By: Brian White <[email protected]>
jasnell added a commit that referenced this pull request May 1, 2017
PR-URL: #12644
Reviewed-By: Brian White <[email protected]>
@jasnell
Copy link
Member Author

jasnell commented May 1, 2017

Landed in 579ff2a, ed0716f, e2199e0, 08809f2 and ea9eed5

@jasnell jasnell closed this May 1, 2017
anchnk pushed a commit to anchnk/node that referenced this pull request May 6, 2017
anchnk pushed a commit to anchnk/node that referenced this pull request May 6, 2017
anchnk pushed a commit to anchnk/node that referenced this pull request May 6, 2017
anchnk pushed a commit to anchnk/node that referenced this pull request May 6, 2017
anchnk pushed a commit to anchnk/node that referenced this pull request May 6, 2017
PR-URL: nodejs#12644
Reviewed-By: Brian White <[email protected]>
@jasnell jasnell mentioned this pull request May 11, 2017
@gibfahn gibfahn mentioned this pull request Jun 15, 2017
3 tasks
@gibfahn
Copy link
Member

gibfahn commented Jun 18, 2017

Should this be backported to v6.x-staging? If yes please follow the guide and raise a backport PR, if no let me know or add the dont-land-on label.

addaleax pushed a commit that referenced this pull request Aug 10, 2017
Updates to use current constructor for freelist, which was changed
under pr #12644

Ref: #12644
PR-URL: #14627
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Gibson Fahnestock <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
addaleax pushed a commit that referenced this pull request Aug 12, 2017
Updates to use current constructor for freelist, which was changed
under pr #12644

Ref: #12644
PR-URL: #14627
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Gibson Fahnestock <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fs Issues and PRs related to the fs subsystem / file system. http Issues or PRs related to the http subsystem. lib / src Issues and PRs related to general changes in the lib or src directory. module Issues and PRs related to the module subsystem. process Issues and PRs related to the process subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants