This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vxgmichel
Recipients asvetlov, vxgmichel, yselivanov
Date 2018-10-26.13:29:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1540560590.22.0.788709270274.issue35065@psf.upfronthosting.co.za>
In-reply-to
Content
I found the culprit:
https://github.com/python/cpython/blob/a05bef4f5be1bcd0df63ec0eb88b64fdde593a86/Lib/asyncio/streams.py#L350

The call to `_untrack_reader` is performed too soon. Closing the transport causes `protocol.connection_lost()` to be "called soon" but by the time it is actually executed, the stream reader has been "untracked".  Since the protocol doesn't know the stream reader anymore, it has not way to feed it the EOF.

The fix attached removes the `_untrack_reader` call and definition altogether. I don't really see the point of this method since one has to wait for `connection_lost` to be executed before untracking the reader, but `connection_lost` already gets rid of the reader reference.

With this fix, calling `writer.close` then awaiting `writer.wait_closed` (or awaiting `writer.aclose`) should:
- close the transport
- schedule `protocol.connection_lost`
- wait for the protocol to be closed
- run `protocol.connection_lost`
- feed the EOF to the reader
- set the protocol as closed
- get rid of the reader reference in the protocol
- return (making aclose causal and safe)
- the reader can then be safely garbage collected

But maybe I'm missing something about `_untrack_reader`?
History
Date User Action Args
2018-10-26 13:29:50vxgmichelsetrecipients: + vxgmichel, asvetlov, yselivanov
2018-10-26 13:29:50vxgmichelsetmessageid: <1540560590.22.0.788709270274.issue35065@psf.upfronthosting.co.za>
2018-10-26 13:29:50vxgmichellinkissue35065 messages
2018-10-26 13:29:50vxgmichelcreate