Hi, 2014-10-12 21:55 GMT+02:00 Guido van Rossum <[email protected]>: > 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
