Skip to content

Conversation

@normanmaurer
Copy link
Member

Motivation:

If we not filled the whole buffer with read(...) we should stop reading and wait until we get notified again. Otherwise chances are good that the next read(...) call will either read nothing or only a very small amount of data.
Also this will allow us to call fireChannelReadComplete() which may give the user the chance to flush out all pending writes.

Modifications:

Stop reading and wait for next wakup when we not fill the whole buffer.

Result:

Less wasted read calls and early chance of flushing out pending data.

@normanmaurer normanmaurer requested review from Lukasa and weissi April 10, 2018 08:40
@normanmaurer
Copy link
Member Author

This also gives a small perf improvement for HTTP benchmarks.

result = .some

if buffer.writableBytes > 0 {
// If we not filled the whole buffer with read(...) we should stop reading and wait until we get notified again.
Copy link
Member

Choose a reason for hiding this comment

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

grammar nit: 'If we did not fill the whole buffer' ...

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed

Copy link
Member

@weissi weissi left a comment

Choose a reason for hiding this comment

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

looks good to me. Approved because you can ignore the grammar nit if you want ;)

@normanmaurer
Copy link
Member Author

@weissi never! Fixed it 👍

@normanmaurer normanmaurer added this to the 1.4.0 milestone Apr 10, 2018
@normanmaurer normanmaurer added the 🔨 semver/patch No public API change. label Apr 10, 2018
@normanmaurer normanmaurer self-assigned this Apr 10, 2018

func errorCaught(ctx: ChannelHandlerContext, error: Error) {
XCTAssertEqual(.read, self.state)
XCTAssertTrue(.read == self.state || .readComplete == self.state)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this non-deterministic?

Copy link
Member Author

Choose a reason for hiding this comment

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

actually I think .readComplete == is the only one we need to test... let me fix

Motivation:

If we not filled the whole buffer with read(...) we should stop reading and wait until we get notified again. Otherwise chances are good that the next read(...) call will either read nothing or only a very small amount of data.
Also this will allow us to call fireChannelReadComplete() which may give the user the chance to flush out all pending writes.

Modifications:

Stop reading and wait for next wakup when we not fill the whole buffer.

Result:

Less wasted read calls and early chance of flushing out pending data.
@normanmaurer
Copy link
Member Author

@Lukasa addressed

Copy link
Contributor

@Lukasa Lukasa left a comment

Choose a reason for hiding this comment

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

I think this LGTM.

@Lukasa
Copy link
Contributor

Lukasa commented Apr 10, 2018

Rebase and merge when ready.

@normanmaurer normanmaurer merged commit 33facfe into apple:master Apr 10, 2018
@normanmaurer normanmaurer deleted the read_change branch April 10, 2018 13:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🔨 semver/patch No public API change.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants