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

FS promises: handle long files reading #19643

Closed
wants to merge 1 commit into from

Conversation

aduh95
Copy link
Contributor

@aduh95 aduh95 commented Mar 27, 2018

Fixes #19443

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

I am not sure about the testing, should I include a very large file on which we can test? On my local machine, I test using the scripts described in the issue.

totalRead += bytesRead;
if (bytesRead > 0)
chunks.push(buffer.slice(0, bytesRead));
} while (totalRead < size);
Copy link
Member

Choose a reason for hiding this comment

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

size cannot be used as a reliable indicator of when the loop should exit since the file size might change while readFileHandle() is running. Maybe what we could do is using bytesRead === chunkSize as the exit condition.

@TimothyGu
Copy link
Member

Thanks for fixing this! In hindsight, the logic errors seem fairly obvious. One comment.

@TimothyGu TimothyGu added fs Issues and PRs related to the fs subsystem / file system. promises Issues and PRs related to ECMAScript promises. labels Mar 27, 2018
@TimothyGu TimothyGu requested a review from jasnell March 27, 2018 20:05
@aduh95 aduh95 force-pushed the fix-fs-promise-readfile branch 2 times, most recently from 49bf54c to 9a9ea11 Compare March 27, 2018 20:48
if (totalRead > 0)
chunks.push(buffer.slice(0, totalRead));
} while (totalRead === chunkSize);
const chunks = [];
Copy link
Contributor

@mscdex mscdex Mar 28, 2018

Choose a reason for hiding this comment

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

This indentation looks off. There's no way this passed make test.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right, I forgot to re-run the tests after TimothyGu change request. My bad!

await read(filehandle, buf, 0, chunkSize, totalRead);
totalRead += bytesRead;
if (bytesRead !== chunkSize)
endOfFile = true;
Copy link
Member

Choose a reason for hiding this comment

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

nit: replace these two lines with endOfFile = bytesRead !== chunkSize;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Isn't that very less efficient to set the variable at each iteration?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

About 5% slower according to the benchmarks I just ran, so "very less" is a bit overstating, still it's not nothing.

Copy link
Member

Choose a reason for hiding this comment

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

Interesting, I assumed it would be faster due to lack of branching (at least it would be in a language like C). Oh well.

@TimothyGu
Copy link
Member

should I include a very large file on which we can test?

How large does it have to be? From the logic itself it seems as if a file larger than 16384 bytes is enough, or am I missing something?

@aduh95
Copy link
Contributor Author

aduh95 commented Mar 28, 2018

@TimothyGu Indeed, 16385 bytes would be enough to check that issue. Should I create such a file in the fixatures folder?

@TimothyGu
Copy link
Member

@aduh95 Yeah that'd work. Or you could find a file in the source tree that's already that big (like AUTHORS).

const { readFile } = require('fs/promises');
const fixtures = require('../common/fixtures');

const fn = fixtures.path('../../AUTHORS');
Copy link
Member

Choose a reason for hiding this comment

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

This seems to defeat the purpose of fixtures. Maybe just create a file with

const tmpdir = require('../common/tmpdir');
tmpdir.refresh();
const fn = path.join(tmpdir.path, 'large-file');
// Write a file and then read it again using `readFile`

Or, create a file with a known hash in fixtures.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good idea, this way I don't need the crypto module anymore for the test

let totalRead = 0;
let endOfFile;
Copy link
Member

Choose a reason for hiding this comment

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

Initialize this to false.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why though?

Copy link
Member

Choose a reason for hiding this comment

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

Better to keep one variable the same type (undefined vs. boolean), when it is used as a boolean anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fair enough

// Creating large buffer with random content
const buffer = Buffer.from(
Array.apply(null, { length: 16834 * 2 })
.map(Number.call, Math.random)
Copy link
Member

Choose a reason for hiding this comment

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

nit: would just .map(Math.random) work?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed

common.crashOnUnhandledRejection();

// Creating large buffer with random content
const buffer = Buffer.from(
Copy link
Member

Choose a reason for hiding this comment

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

You can generate this buffer with crypto.randomBytes(16834 * 2) actually, but the current method LGTM anyway.

@BridgeAR
Copy link
Member

BridgeAR commented Apr 9, 2018

@aduh95
Copy link
Contributor Author

aduh95 commented Apr 10, 2018

I am a bit confused about the CI result...
Does that mean this PR fails on some architectures? Where can I find info to solve it? (Sorry, I am newbie on the subject)

@jasnell
Copy link
Member

jasnell commented Apr 14, 2018

Lots of red in the CI results that appear to be build bot failures... trying again https://ci.nodejs.org/job/node-test-pull-request/14293/

@aduh95 aduh95 closed this Apr 15, 2018
@aduh95 aduh95 deleted the fix-fs-promise-readfile branch April 15, 2018 19:20
@aduh95 aduh95 restored the fix-fs-promise-readfile branch April 15, 2018 19:21
@aduh95 aduh95 reopened this Apr 15, 2018
@TimothyGu TimothyGu added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Apr 15, 2018
@TimothyGu
Copy link
Member

One last CI run: https://ci.nodejs.org/job/node-test-pull-request/14315/

@TimothyGu
Copy link
Member

CI passes (after a rerun on AIX). Landed in 11819c7.

@TimothyGu TimothyGu closed this Apr 16, 2018
TimothyGu pushed a commit that referenced this pull request Apr 16, 2018
PR-URL: #19643
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
jasnell pushed a commit that referenced this pull request Apr 16, 2018
PR-URL: #19643
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
@BridgeAR
Copy link
Member

BridgeAR commented May 1, 2018

This is based on a semver-major as far as I know, so I marked them as do not land on the other release lines.

@aduh95 aduh95 deleted the fix-fs-promise-readfile branch May 1, 2018 20:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. fs Issues and PRs related to the fs subsystem / file system. promises Issues and PRs related to ECMAScript promises.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FS promises does not work well with big files
7 participants