Skip to content

Fix bug in datagram message due to shared buffer #34

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

Merged
merged 1 commit into from
Oct 11, 2016

Conversation

cezarsa
Copy link
Contributor

@cezarsa cezarsa commented Oct 11, 2016

This bug was introduced by me in 8487663 and I'm deeply sorry for that. The problem is that as the DatagramMessage channel is buffered we cannot simply use the same buffer for reading all incoming datagrams, because reading will change the []byte for all messages still buffered in the channel.

I added some tests that fail on the previous version in the hope of avoiding this same mistake in the future.

The solution was using a sync.Pool instance to acquire a buffer and putting it back on the pool only once it's been received and processed. This solution has the same advantages of reusing the buffer without the risk of changing a buffer still in use. And for some reason it seems even faster than simply using the same buffer:

benchmark                           old ns/op     new ns/op     delta
BenchmarkDatagramNoFormatting-4     2693          2398          -10.95%

benchmark                           old MB/s     new MB/s     speedup
BenchmarkDatagramNoFormatting-4     17.45        19.59        1.12x

benchmark                           old allocs     new allocs     delta
BenchmarkDatagramNoFormatting-4     4              5              +25.00%

benchmark                           old bytes     new bytes     delta
BenchmarkDatagramNoFormatting-4     368           487           +32.34%

This bug was introduced by me in 8487663
and I'm sorry for that. The problem is that as the DatagramMessage
channel is buffered we cannot simply use the same buffer for reading all
incoming datagrams, because reading will change the []byte for all
messages still buffered in the channel.

I added some tests that fail on the previous version in the hope of
avoiding this same mistake in the future.

The solution was using a sync.Pool instance to acquire a buffer and
putting it back on the pool only when it was received and processed.
This solution has the same advantages of reusing the buffer without
the risk of changing a buffer still in use. And for some reason it
seems even faster than simply using the same buffer:

benchmark                           old ns/op     new ns/op     delta
BenchmarkDatagramNoFormatting-4     2693          2398          -10.95%

benchmark                           old MB/s     new MB/s     speedup
BenchmarkDatagramNoFormatting-4     17.45        19.59        1.12x

benchmark                           old allocs     new allocs     delta
BenchmarkDatagramNoFormatting-4     4              5              +25.00%

benchmark                           old bytes     new bytes     delta
BenchmarkDatagramNoFormatting-4     368           487           +32.34%
@mcuadros mcuadros closed this Oct 11, 2016
@mcuadros mcuadros reopened this Oct 11, 2016
@mcuadros mcuadros merged commit 9cf13b7 into mcuadros:master Oct 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants