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: reduced duplicate code in fs.write() #2947

Closed
wants to merge 1 commit into from

Conversation

ronkorving
Copy link
Contributor

No description provided.

@thefourtheye thefourtheye added the fs Issues and PRs related to the fs subsystem / file system. label Sep 18, 2015
@thefourtheye
Copy link
Contributor

LGTM

@ronkorving
Copy link
Contributor Author

Amusingly btw, the names for strWrapper and bufWrapper were reversed:

  • bufWrapper was used for strings, and its internal comment referred to strings
  • strWrapper was used for Buffer, and its internal comment referred to Buffer

Anyway, that doesn't matter anymore as they've been unified now.

@thefourtheye
Copy link
Contributor

@vkurchatkin
Copy link
Contributor

I think this was actually done on purpose to avoid polymorphism

@thefourtheye
Copy link
Contributor

@vkurchatkin Could you please elaborate?

@mscdex
Copy link
Contributor

mscdex commented Sep 18, 2015

@thefourtheye FWIW this blog post explains mono/poly/mega-morphism (how it relates to v8/JavaScript) pretty well.

@ajafff
Copy link
Contributor

ajafff commented Sep 18, 2015

I think this was actually done on purpose to avoid polymorphism

Correct me if I'm wrong:
That does only apply if you access any property of the object, doesn't it?
Here we are just holding a reference and pass it to the callback -> no property access -> no polimorphism

@mscdex
Copy link
Contributor

mscdex commented Sep 19, 2015

After looking at FSWrapReq, it looks like the function arguments are always the same types for a write operation, so I think @meinklaus is right here.

@ronkorving
Copy link
Contributor Author

Any blockers?

@brendanashworth
Copy link
Contributor

LGTM if the CI is happy. For the record, I don't even know if keeping a reference to the string is necessary ("external" strings? this isn't handled elsewhere afaik).

@ronkorving
Copy link
Contributor Author

I don't know either to be honest. @trevnorris may know more on this. I don't see that as a blocker for this PR, but if we can get clarity on that, of course I can update the PR if needed. I wouldn't want to introduce risk though.

@trevnorris
Copy link
Contributor

IIRC you had a fix like this before. LGTM. I'm the one who did it this way. Was b/c I was overly strict about where I placed that assignment. Wasn't actually needed.

@ronkorving
Copy link
Contributor Author

In the previous PR it was about buffers, this time it's about a string (well, the conversation is). Are you saying I can remove buffer from that wrapper altogether? Or only in the case of strings? Or am I misunderstanding? In any case, it does seem like we need the wrapper to ensure we return the number of bytes written (although I have a hard time believing that C++ land won't return a number as the 2nd argument, but I can look into that).

@trevnorris
Copy link
Contributor

I'm on crack. Was referring to changing the location of req.oncomplete = wrapper;

As for maintaining a reference to the string, when the string is externalized a reference has to be kept. Since we used the external memory from the string object. So if the string is GC'd while the data is written it can blow up.

@ronkorving
Copy link
Contributor Author

Got it, thanks. Sounds like we're all good then :)

@trevnorris
Copy link
Contributor

Yup. LGTM

@ronkorving
Copy link
Contributor Author

Looking forward to seeing it merged :) Anything I can do to speed that up?

@trevnorris
Copy link
Contributor

Whoops. Sorry. Running CI to verify everything is fine: https://ci.nodejs.org/job/node-test-pull-request/627/

trevnorris pushed a commit that referenced this pull request Oct 27, 2015
PR-URL: #2947
Reviewed-By: Sakthipriyan Vairamani <[email protected]>
Reviewed-By: Trevor Norris <[email protected]>
@trevnorris
Copy link
Contributor

Bugger. NM. ^F failed me, didn't see the CI run that @thefourtheye posted above.

Landed in c339fa3. Thanks much!

@trevnorris trevnorris closed this Oct 27, 2015
@jasnell
Copy link
Member

jasnell commented Oct 27, 2015

@trevnorris @thefourtheye @vkurchatkin ... should this also go into v4.x?

@trevnorris
Copy link
Contributor

@jasnell code cleanup, no bug fix but also no side-effects. might be useful to have if landing future patches in the same code in the future.

jasnell pushed a commit that referenced this pull request Oct 28, 2015
PR-URL: #2947
Reviewed-By: Sakthipriyan Vairamani <[email protected]>
Reviewed-By: Trevor Norris <[email protected]>
@jasnell
Copy link
Member

jasnell commented Oct 28, 2015

Landed in v4.x-staging in fb3b848

rvagg pushed a commit to rvagg/io.js that referenced this pull request Oct 29, 2015
PR-URL: nodejs#2947
Reviewed-By: Sakthipriyan Vairamani <[email protected]>
Reviewed-By: Trevor Norris <[email protected]>
@rvagg rvagg mentioned this pull request Oct 29, 2015
jasnell pushed a commit that referenced this pull request Oct 29, 2015
PR-URL: #2947
Reviewed-By: Sakthipriyan Vairamani <[email protected]>
Reviewed-By: Trevor Norris <[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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants