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

udp/stream: use MaybeStackBuffers to manage buffer memory management #8626

Closed
wants to merge 3 commits into from

Conversation

pkiddie
Copy link

@pkiddie pkiddie commented Sep 17, 2016

Checklist
  • make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

udp
stream

Description of change

The uv_buf_t bufs_[16] lines could be MaybeStackBuffers; as nodejs/code-and-learn#56

Paul Kiddie added 2 commits September 17, 2016 10:45
instead of creating own buffer, use MaybeStackBuffer on DoSend to take advantage of its destructor to free up memory, so buffer never leaks memory - even if code in DoSend throws.
Use MaybeStackBuffer in Writev to take advantage of destructor on MaybeStackBuffer to clear itself up, rather than Writev managing resources itself.
@nodejs-github-bot nodejs-github-bot added the c++ Issues and PRs that require attention from people who are familiar with C++. label Sep 17, 2016
@@ -102,8 +102,7 @@ int StreamBase::Writev(const FunctionCallbackInfo<Value>& args) {

size_t count = chunks->Length() >> 1;

uv_buf_t bufs_[16];
uv_buf_t* bufs = bufs_;
MaybeStackBuffer<uv_buf_t> bufs(count);
Copy link
Member

Choose a reason for hiding this comment

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

Can you use MaybeStackBuffer<uv_buf_t, 16>? That should keep the current default size, which seems reasonable to me

Copy link
Author

Choose a reason for hiding this comment

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

sure, but still pass in count when creating it as I'm doing?

Or should I reinstate l135-137 to create the bigger buffer if required?

Copy link
Member

Choose a reason for hiding this comment

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

MaybeStackBuffer does exactly that – it creates a bigger buffer of count entries when the static buffer is not large enough. :) So, yes, both a default of 16 as the second template parameter, and count as the second parameter.

Copy link
Author

Choose a reason for hiding this comment

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

Excellent. I suppose the same change should be made for for udp_wrap.cc too a345322?diff=split#diff-b62464f44488c6247346b82a87cbd20aL278

Copy link
Member

Choose a reason for hiding this comment

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

@pkiddie yup :)

@mscdex mscdex added the dgram Issues and PRs related to the dgram subsystem / UDP. label Sep 17, 2016
@imyller
Copy link
Member

imyller commented Sep 17, 2016

Copy link
Member

@addaleax addaleax left a comment

Choose a reason for hiding this comment

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

CI looks good, and a +4 −22 diff is always good news!

It would be really great if you could squash the commits, reformat the commit message so that it starts with src: (we usually do that for cleanup changes to src/) and the title line is no longer than 50 characters.

That can also be done when landing the commit, if you prefer.

@pkiddie
Copy link
Author

pkiddie commented Sep 20, 2016

Thanks @addaleax. I'm on leave without access to git but back early next week so will pick it up then:) thanks for your help.

@addaleax
Copy link
Member

@pkiddie That would mean it’s probably easiest to clean up the commit message when merging the commit, unless you’d prefer to do it yourself?

@pkiddie
Copy link
Author

pkiddie commented Sep 20, 2016

@addaleax Happy for it to be merged and the message cleaned up, rather than wait on me

addaleax pushed a commit that referenced this pull request Sep 20, 2016
instead of creating own buffer, use MaybeStackBuffer on DoSend to
take advantage of its destructor to free up memory, so buffer
never leaks memory - even if code in DoSend throws.

Use MaybeStackBuffer in Writev to take advantage of destructor
on MaybeStackBuffer to clear itself up, rather than Writev managing
resources itself.

PR-URL: #8626
Reviewed-By: Anna Henningsen <[email protected]>
@addaleax addaleax added the lib / src Issues and PRs related to general changes in the lib or src directory. label Sep 20, 2016
@addaleax
Copy link
Member

Landed in fffb9a3 with squashed commit message, thank you for doing this! 🎉

@addaleax addaleax closed this Sep 20, 2016
Fishrock123 pushed a commit that referenced this pull request Oct 11, 2016
instead of creating own buffer, use MaybeStackBuffer on DoSend to
take advantage of its destructor to free up memory, so buffer
never leaks memory - even if code in DoSend throws.

Use MaybeStackBuffer in Writev to take advantage of destructor
on MaybeStackBuffer to clear itself up, rather than Writev managing
resources itself.

PR-URL: #8626
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
c++ Issues and PRs that require attention from people who are familiar with C++. dgram Issues and PRs related to the dgram subsystem / UDP. lib / src Issues and PRs related to general changes in the lib or src directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants