This repository has been archived by the owner on Sep 13, 2024. It is now read-only.
transports: Close socket when closing the transport #52
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Merely detaching leads to the socket still being open, and thus behaves
differently from Python's asyncio where .close() on the transport also
closes the socket.
When calling
.close()
on a TCP socket, unlike in upstream asyncio, this does not cause the TCP connection to be closed, but merely leaks the file descriptor (which is what.detach()
on a socket is described to do in the Python documentation).This is precisly a revert of f900d41 -- @dob3001 might have ideas why this is a bad idea, or check against the original use case. I couldn't do that because #47 contains no further explanations. Possibly, the file descriptor was still used in earlier versions of gbulb by something that'd close it, and now that other component was changed.
The problem was observed when running aiocoap with the gbulb loop; while all its test cases run through on several Python versions with asyncio, the TCP tests hang on gbulb. To observe what gbulb is doing it is easier to run, in a checked out aiocoap master branch, the command
AIOCOAP_TESTS_LOOP=gbulb python3 -m tests.test_server
and on a different terminalsocat - tcp6:localhost:5683
. Entering0000<Enter>
leads to the termination of the connection on asyncio, and just the error message (but no TCP connetion termination) on gbulb. It's probably possible to make this into a more minimal proof of different behavior, but so far I hope that this relatively laborious process won't be necessary here.PR Checklist:
(No new features were added; a tox run skipped a few interpreters but completed the tests on 3.9. towncrier, package and docs failed on dependencies but should not be relevant to this commit)
(There are no new features)