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: document why isPerformingIO is required #33982

Closed
wants to merge 2 commits into from

Conversation

ronag
Copy link
Member

@ronag ronag commented Jun 19, 2020

Adds some notes to motivate why isPerformingIO is required for any future developers unfamiliar with it.

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

@ronag ronag added the fs Issues and PRs related to the fs subsystem / file system. label Jun 19, 2020
@ronag ronag requested a review from addaleax June 19, 2020 22:14
@ronag
Copy link
Member Author

ronag commented Jun 19, 2020

@addaleax: PTAL to ensure the description is correct.

Copy link
Member

@trivikr trivikr left a comment

Choose a reason for hiding this comment

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

LGTM, minor nits

lib/internal/fs/streams.js Outdated Show resolved Hide resolved
lib/internal/fs/streams.js Outdated Show resolved Hide resolved
@ronag ronag added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jun 20, 2020
@ronag
Copy link
Member Author

ronag commented Jun 20, 2020

@addaleax: Would it make sense to add guards for this one level lower, i.e. in fs.read/write and fs.close? I'm a little worried that when users use these methods directly they don't take this edge case into consideration (just like we missed it in fs streams).

@addaleax
Copy link
Member

@ronag Yes, but how? We can’t assign those properties to the fd itself, even though that would make the most sense here… it might be worth for FileHandle, though.

@ronag
Copy link
Member Author

ronag commented Jun 20, 2020

We can’t assign those properties to the fd itself

We could have a Map<FD, state>? With some performance overhead...

Would it be possible to use FileHandle for the callback version as well?

@addaleax
Copy link
Member

@ronag Yes… I’m just worried we’ll run into problems – what if the user passes the fd to an addon? We can’t know what happens with that fd in that case. I’m all for it, though – I’ve thought about doing this for Worker threads too, at least optionally, because they should really close all fds that they have created during their lifetime.

@ronag
Copy link
Member Author

ronag commented Jun 20, 2020

We can’t know what happens with that fd in that case.

Is it maybe possible to fix this whole thing in libuv? It kind of feels like a "bug" to me...

@addaleax
Copy link
Member

@ronag I don’t think we could do it any better than in Node.js, i.e. it would have to be on a best-effort basis.

@ronag
Copy link
Member Author

ronag commented Jun 20, 2020

Would moving to e.g. io_uring on at least linux resolve this?

@ronag
Copy link
Member Author

ronag commented Jun 20, 2020

what if the user passes the fd to an addon?

Could napi have guards?

@addaleax
Copy link
Member

Would moving to e.g. io_uring on at least linux resolve this?

Not that I know of – they still pass fds as raw numbers?

what if the user passes the fd to an addon?

Could napi have guards?

No, we can’t tell fds apart from other integers, unfortunately.

(These are all reasons why FileHandle is a lot nicer than the standard fs API.)

@ronag
Copy link
Member Author

ronag commented Jun 20, 2020

Not that I know of – they still pass fds as raw numbers?

Yes, I think ioring would avoid the need for threads and sync api's... i.e. removing the underlying issue.

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

ronag added a commit that referenced this pull request Jun 21, 2020
PR-URL: #33982
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Trivikram Kamat <[email protected]>
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
@ronag
Copy link
Member Author

ronag commented Jun 21, 2020

Landed in 51a2df4

@MylesBorins
Copy link
Contributor

This is not landing cleanly on v14.x. @ronag should we backport?

@ronag
Copy link
Member Author

ronag commented Jul 14, 2020

@MylesBorins: No I think we can skip this. It's mostly for future reference in development.

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants