Hi,
2014-10-12 21:55 GMT+02:00 Guido van Rossum <
gu...@python.org>:
> So you're only concerned about the streams example, right?
Oh no sorry, my question was general. It's just that I discovered the
issue when working on these examples for the documentation.
> - writer.close() calls self._transport.close(), which is
> _SelectorTransport.close()
> - that removes the socket from the selector and schedules a call to
> _call_connection_lost
It only calls immedialty _call_connection_lost() if the write buffer is empty.
Right now, it's not clear for me what "close" means, and it's not well
documented. When I close a file descriptor, I except that future read
and write operations will fail. Usually, all operations are blocking,
so I don't have to worry of on-going operations.
In asyncio, it looks like closing a transport stops immediatly reading
but writing is still possible. So it's possible to write into a closed
transport. Is that correct? It looks like transport.write_eof() is the
way to block *future* write operations.
My question is: how can I ensure a connection is completly closed?
Buffer flushed, transport closed, etc.? Or said differently, what is
the safest way to close a connection controlled by a pair of (reader,
writer) streams?
Is it safer to call write_eof() before close()?
Transport.close() documentation says "buffered data will be flushed
asynchronously". Does it mean that close() must be followed by "yield
from writer.drain()"?
https://docs.python.org/dev/library/asyncio-protocol.html#asyncio.BaseTransport.close
(I'm still asking for the general case, for example when I don't
control all operations done on the reader nor the writer.)
Victor