Skip to content
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

asyncnet: don't try to close the socket again [backport] #15174

Merged
merged 1 commit into from
Aug 12, 2020

Conversation

alaviss
Copy link
Collaborator

@alaviss alaviss commented Aug 11, 2020

The closed flag here doesn't seem to be a a good design to me, but until
I can understand why it was needed it seems unwise to just replace it
with the invalidation of the socket.

Fixes #9867 (comment)

/cc @dom96 as this closed flag was added by him. This flag appear to have survived the refactoring in 1661062, where its sister net module use the different approach of invalidating the Socket instead of a flag.

@alaviss alaviss changed the title asyncnet: don't try to close the socket again asyncnet: don't try to close the socket again [backport] Aug 11, 2020
Copy link
Contributor

@dom96 dom96 left a comment

Choose a reason for hiding this comment

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

IMO an exception should be raised if you try to close an already closed socket. Maybe you can raise an exception instead of doing nothing?

elif res != 1:
raiseSSLError()
socket.closed = true # TODO: Add extra debugging checks for this.
if not socket.closed:
Copy link
Contributor

Choose a reason for hiding this comment

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

Prefer:

if socket.closed: return

Style rather than wrapping everything in more and more nested ifs.

Copy link
Member

Choose a reason for hiding this comment

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

No, nested ifs are better.

The closed flag isn't a good design by any means, but let's have this
working first before I get rid of the flag and potentially create a
non-backportable commit.
@alaviss
Copy link
Collaborator Author

alaviss commented Aug 11, 2020

IMO an exception should be raised if you try to close an already closed socket. Maybe you can raise an exception instead of doing nothing.

net currently doesn't raise any exception so we shouldn't raise any here either.

@dom96
Copy link
Contributor

dom96 commented Aug 11, 2020

it always calls close on the fd though, maybe that will raise?

@alaviss
Copy link
Collaborator Author

alaviss commented Aug 11, 2020

Nah, nativesockets.close() ignores all errors.

@dom96
Copy link
Contributor

dom96 commented Aug 11, 2020

That sounds dangerous, but alright, in any case I would still match the semantics in net and call close nevertheless.

@alaviss
Copy link
Collaborator Author

alaviss commented Aug 11, 2020

Currently I'm not doing that because I'm not invalidating the socket. I can certainly do so, but IMO it's better to do that with the follow up refactoring to get rid of the closed flag.

@Araq Araq merged commit 957bf15 into nim-lang:devel Aug 12, 2020
@alaviss alaviss deleted the asyncnet-double-close-fix branch August 12, 2020 20:29
narimiran pushed a commit that referenced this pull request Sep 11, 2020
The closed flag isn't a good design by any means, but let's have this
working first before I get rid of the flag and potentially create a
non-backportable commit.

(cherry picked from commit 957bf15)
narimiran pushed a commit that referenced this pull request Sep 11, 2020
The closed flag isn't a good design by any means, but let's have this
working first before I get rid of the flag and potentially create a
non-backportable commit.

(cherry picked from commit 957bf15)
mildred pushed a commit to mildred/Nim that referenced this pull request Jan 11, 2021
)

The closed flag isn't a good design by any means, but let's have this
working first before I get rid of the flag and potentially create a
non-backportable commit.
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.

Long-lived application occasionally dies with SIG_PIPE when calling httpclient.request
3 participants