Skip to content
This repository was archived by the owner on Feb 24, 2020. It is now read-only.

Conversation

@s-urbaniak
Copy link
Contributor

@s-urbaniak s-urbaniak commented Nov 16, 2016

This PR implements the NopCloser()-like function NopReadSeekCloser() and some other cleanups related to the removing of isReallyNil().

Fixes #2922

Supersedes #3120

Copy link
Collaborator

@krnowak krnowak left a comment

Choose a reason for hiding this comment

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

I wrote this code long time ago, so I may be wrong with my review.

if err != nil {
return nil, err
}
defer func() { maybeClose(roc) }()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does that cause roc to be "leaked" when if url.Parse(location) fails?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed

if err != nil {
return nil, errwrap.Wrap(errors.New("error opening ACI file"), err)
}
defer func() { maybeClose(aciFile) }()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does that cause the aciFile to "leak" if newValidator fails?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed

if err != nil {
return nil, nil, err
}
defer func() { maybeClose(aciFile) }()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does this cause aciFile to "leak" if cd.UseCached is true?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed

session := o.getSession(u, aciFile.File, "ACI", etag)
dl := o.getDownloader(session)
if err := dl.Download(u, aciFile.File); err != nil {
aciFile.Close() // download failed, close the aciFile to implicitely release the lock
Copy link
Collaborator

Choose a reason for hiding this comment

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

Aha, there you can see why I added this maybeClose function… To avoid closing the file in every error case. Instead I preferred the deffered maybeClose function call that does nothing if aciFile became nil (which would happen if no errors happened).

Copy link
Collaborator

Choose a reason for hiding this comment

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

Also, a typo - should be implicitly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed, this is indeed the biggest benefit of maybeClose.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And also agreed, that this PR introduces a stylistic nuance. Nevertheless I believe that (fortunately, or unfortunately) this is Go's nature, namely being pretty verbose, especially in error cases. The biggest pro of maybeClose is, that it reduces LOC, but it made it hard to reason about when these files were actually "really" closed. This will make the reasoning easier at the expense of verbosity.

if err != nil {
return nil, nil, err
}
defer func() { maybeClose(aciFile) }()
Copy link
Collaborator

Choose a reason for hiding this comment

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

You are closing this if download fails, but you still leak it if cd.UseCached is true

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed

@s-urbaniak
Copy link
Contributor Author

@krnowak thanks a lot for chiming in! o/ :-) I just took over, and you are very right in your assertion regarding the above leaks, thanks!

@s-urbaniak s-urbaniak changed the title This PR implements the NopCloser()-like function NopReadSeekCloser() and some other cleanups related to the removing of isReallyNil(). remove isReallyNil() Nov 16, 2016
@s-urbaniak s-urbaniak changed the title remove isReallyNil() [WIP] remove isReallyNil() Nov 16, 2016
@s-urbaniak s-urbaniak changed the title [WIP] remove isReallyNil() remove isReallyNil() Nov 16, 2016
@s-urbaniak s-urbaniak force-pushed the 2922-remove-isreallynil branch 2 times, most recently from 55bcee4 to ad0ca49 Compare November 17, 2016 09:04
@s-urbaniak s-urbaniak force-pushed the 2922-remove-isreallynil branch 3 times, most recently from d6b7657 to 3904043 Compare November 18, 2016 10:03
isReallyNil uses reflection to evaluate whether a given readSeekCloser
is "really nil" to optionally close it. While it removes the burden of
explicitly closing resources it is not obvious when it happens.

This removes the function.

Fixes rkt#2922
@s-urbaniak s-urbaniak force-pushed the 2922-remove-isreallynil branch from 3904043 to b9ffaa4 Compare November 18, 2016 10:10
Copy link
Member

@lucab lucab left a comment

Choose a reason for hiding this comment

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

A couple of iterations offline, and now it's LGTM.

@s-urbaniak
Copy link
Contributor Author

build failures are caused by a known flake TestNetDefaultRestrictedConnectivity, hence merging.

@s-urbaniak s-urbaniak merged commit de1eb09 into rkt:master Nov 18, 2016
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