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

Removed grpc_byte_buffer_reader_{create,destroy}. #1866

Merged
merged 2 commits into from
Jun 2, 2015

Conversation

dgquintas
Copy link
Contributor

Introduced grpc_byte_buffer_init instead. It's now the user's responsibility to manage memory.

Introduced grpc_byte_buffer_init instead. It's now the user's responsibility to
manage memory.
/* At the end of the stream, returns 0. Otherwise, returns 1 and sets slice to
be the returned slice. Caller is responsible for calling gpr_slice_unref on
the result. */
int grpc_byte_buffer_reader_next(grpc_byte_buffer_reader *reader,
gpr_slice *slice);
void grpc_byte_buffer_reader_destroy(grpc_byte_buffer_reader *reader);
Copy link
Member

Choose a reason for hiding this comment

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

It might be worth keeping this API, even as a no-op for now.

What happens if we need to allocate some memory in order to read the byte buffer?
(for instance: decompressing it into a temporary slice buffer?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The idea being to encapsulate the creation/destruction, as opposed to having the user gpr_malloc+grpc_bb_reader_init / gpr_free "in the open"?

Copy link
Member

Choose a reason for hiding this comment

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

Right... so:

grpc_byte_buffer_reader r;
grpc_byte_buffer_reader_init(&r, ...);
// do some wonderful things
grpc_byte_buffer_reader_destroy(&r);

On Mon, Jun 1, 2015 at 9:51 PM David G. Quintas notifications@github.com
wrote:

In include/grpc/grpc.h
#1866 (comment):

/* At the end of the stream, returns 0. Otherwise, returns 1 and sets slice to
be the returned slice. Caller is responsible for calling gpr_slice_unref on
the result. */
int grpc_byte_buffer_reader_next(grpc_byte_buffer_reader *reader,
gpr_slice *slice);
-void grpc_byte_buffer_reader_destroy(grpc_byte_buffer_reader *reader);

The idea being to encapsulate the creation/destruction, as opposed to
having the user gpr_{malloc,free} "in the open"?


Reply to this email directly or view it on GitHub
https://github.com/grpc/grpc/pull/1866/files#r31492707.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ack.

@dgquintas
Copy link
Contributor Author

Node failure is possibly unrelated to the change, independently reported in #1867

As a no-op for the time being.
@dgquintas
Copy link
Contributor Author

Comments addressed.

gpr_slice next;
while (grpc_byte_buffer_reader_next(reader, &next) != 0) {
while (grpc_byte_buffer_reader_next(&reader, &next) != 0) {
memcpy(result + offset, GPR_SLICE_START_PTR(next), GPR_SLICE_LENGTH(next));
offset += GPR_SLICE_LENGTH(next);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It looks like there used to be a leak here: no mention of grpc_byte_buffer_reader_destroy

ctiller added a commit that referenced this pull request Jun 2, 2015
Removed grpc_byte_buffer_reader_{create,destroy}.
@ctiller ctiller merged commit 669c139 into grpc:master Jun 2, 2015
@lock lock bot locked as resolved and limited conversation to collaborators Jan 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants