Skip to content

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 <thechargingvolcano@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
@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 <thechargingvolcano@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
@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 <thechargingvolcano@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
@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 <thechargingvolcano@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
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