Skip to content

packet: fix misusing of defer #729

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
Sep 7, 2022

Conversation

shizhx
Copy link
Contributor

@shizhx shizhx commented Sep 7, 2022

defer capture arguments at once, so modify arguments after defer line not works
Closes #728

defer capture arguments at once, so modify arguments after defer line not works
Copy link
Collaborator

@lance6716 lance6716 left a comment

Choose a reason for hiding this comment

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

Thanks for fixing it!

Just for discussing, do you think we should also remove two buf = nil below? Because we know BytesBufferPut can skip putting it back to cache pool when it's too big.
But line 113 "exposing the buf.Bytes() to caller" must be used along with "not putting buf back to cache pool". Explicitly assigning buf to nil is better than implicitly doing it in BytesBufferPut.

For now I slightly prefer we remove the buf = nil in line 108 and its if-block. What do you think?

@shizhx
Copy link
Contributor Author

shizhx commented Sep 7, 2022

If we remove the buf = nil line, we need to add a new API to achieve "copy buffer" feature, maybe utils.BytesBufferCopyAndPut or a better name, the new API implementation can decide between "actually copy buffer" and "return buffer".

But the new API only suitable for successful return, failed return we also have to call "BytesBufferPut".

So, I think removing the buf = nil line is difficult.

@lance6716
Copy link
Collaborator

I can't understand why we need to add a new API to remove buf = nil. Can you explain why current code plus deleting buf = nil is not proper?

@shizhx
Copy link
Contributor Author

shizhx commented Sep 7, 2022

I can't understand why we need to add a new API to remove buf = nil. Can you explain why current code plus deleting buf = nil is not proper?

as your post above:

But line 113 "exposing the buf.Bytes() to caller" must be used along with "not putting buf back to cache pool". Explicitly assigning buf to nil is better than implicitly doing it in BytesBufferPut.

If we simply remove the buf = nil line, when the put or not condition changed in BytesBufferPut, current code maybe buggy.

So we need an explicit API to do it, maybe a BytesBufferCopyAndPut or IsBytesBufferActuallyPut.

@atercattus
Copy link
Member

Hello.
What is wrong with defer here? :) buf is a *bytes.Buffer, and we do not modify it (expect buf = nil cases).

@shizhx
Copy link
Contributor Author

shizhx commented Sep 7, 2022

@atercattus The following code buf = nil want utils.BytesBufferPut(nil) to prevent actually put buf. but defer utils.BytesBufferPut(buf) cannot achieve that, always non-nil argument passed to utils.BytesBufferPut.

@atercattus
Copy link
Member

Oh, sorry, I'm blind :)
It's my fault, I missed it in #651.

And I agree what a better way is wrap defer to func here.

@lance6716 lance6716 merged commit 8eb93a4 into go-mysql-org:master Sep 7, 2022
@shizhx shizhx deleted the bugfix_misusing_defer_728 branch September 7, 2022 08:44
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.

Misusing of defer
3 participants