Skip to content

Do not double close reader #29354

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 3 commits into from
Feb 24, 2024
Merged

Do not double close reader #29354

merged 3 commits into from
Feb 24, 2024
+11 −4

Conversation

KN4CK3R
Copy link
Member

@KN4CK3R KN4CK3R commented Feb 23, 2024

Fixes #29346

@KN4CK3R KN4CK3R added type/bug backport/v1.21 This PR should be backported to Gitea 1.21 labels Feb 23, 2024
@KN4CK3R KN4CK3R added this to the 1.22.0 milestone Feb 23, 2024
@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Feb 23, 2024
KN4CK3R
KN4CK3R commented Feb 23, 2024
View reviewed changes
modules/git/blob_nogogit.go Outdated
Comment on lines 106 to 108
if b.rd == nil {
return fs.ErrClosed
}
Copy link
Member Author

Choose a reason for hiding this comment

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

Should it panic here instead? Calling Close multiple times is a coding error. I checked all calls to DataAsync and could not find another double close. A panic could prevent double closes in future while returning a (most of time) ignored error could hide it.

Copy link
Contributor

Choose a reason for hiding this comment

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

No. None of Golang's other "Close" methods panics.

Copy link
Contributor

Choose a reason for hiding this comment

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

Could it simply return "nil"? Most (all) errors for a Close method are meanless .... no caller cares about it.

Copy link
Member

Choose a reason for hiding this comment

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

I think double Close should be supported. i.e. It's safe to invoke file.Close twice. So I think we should also allow invoking Close twice. It's convenient for some situations.

Copy link
Member Author

Choose a reason for hiding this comment

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

Should we then add this rule to our coding guidelines?

If a type implements io.Closer, calling Close multiple times must not fail and return a nil error.

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess it depends, for most cases: yes, nil is good enough.

But I guess there could be some special cases that the caller might be interested in the result.

Copy link
Member Author

Choose a reason for hiding this comment

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

Then maybe relax the nil but specify that calling Close multiple times must not be undefined behaviour and must not panic?

@KN4CK3R KN4CK3R mentioned this pull request Feb 23, 2024
Closed
wxiaoguang
wxiaoguang approved these changes Feb 24, 2024
View reviewed changes
Copy link
Contributor

@wxiaoguang wxiaoguang left a comment

Choose a reason for hiding this comment

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

Prefer to return "nil". But could LGTM ahead.

@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Feb 24, 2024
lunny
lunny approved these changes Feb 24, 2024
View reviewed changes
Copy link
Member

@lunny lunny left a comment

Choose a reason for hiding this comment

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

return nil is better.

@GiteaBot GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Feb 24, 2024
@wxiaoguang wxiaoguang added the reviewed/wait-merge This pull request is part of the merge queue. It will be merged soon. label Feb 24, 2024
@wxiaoguang wxiaoguang enabled auto-merge (squash) February 24, 2024 11:34
@wxiaoguang wxiaoguang merged commit 553d46e into go-gitea:main Feb 24, 2024
GiteaBot pushed a commit to GiteaBot/gitea that referenced this pull request Feb 24, 2024
@KN4CK3R @wxiaoguang @GiteaBot
Do not double close reader (go-gitea#29354)
8a4d3d0 
Fixes go-gitea#29346

---------

Co-authored-by: wxiaoguang <[email protected]>
@GiteaBot GiteaBot mentioned this pull request Feb 24, 2024
Merged
@GiteaBot GiteaBot added backport/done All backports for this PR have been created and removed reviewed/wait-merge This pull request is part of the merge queue. It will be merged soon. labels Feb 24, 2024
silverwind pushed a commit that referenced this pull request Feb 24, 2024
@GiteaBot @KN4CK3R @wxiaoguang
Do not double close reader (#29354) (#29370)
e75594f 
Backport #29354 by @KN4CK3R

Fixes #29346

Co-authored-by: KN4CK3R <[email protected]>
Co-authored-by: wxiaoguang <[email protected]>
@KN4CK3R KN4CK3R deleted the fix-double-close branch February 24, 2024 22:51
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@wxiaoguang wxiaoguang wxiaoguang approved these changes

@lunny lunny lunny approved these changes

Assignees
No one assigned
Labels
backport/done All backports for this PR have been created backport/v1.21 This PR should be backported to Gitea 1.21 lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. type/bug
Projects
None yet
Milestone
1.22.0
Development

Successfully merging this pull request may close these issues.

Edit file times out for large files after recent cat-file bugfix
4 participants
@KN4CK3R @lunny @wxiaoguang @GiteaBot