Yes, writer.close() closes the transport, which (eventually) closes both ends of the socket.
In general a socket or pipe is closed by its transport right after connection_lost() is called. This happens either when it finds out that the remote end is closed, or when transport.close() is called (e.g. by writer.close()). There may be a delay, because connection_lost() is always scheduled via the event loop. Closing the event loop does not close the sockets! (To the contrary, it prevents scheduled callbacks to run.) I think your example has a bug: it reads until EOF instead of until a blank line. (And this may hang because HTTP servers may keep the connection open.) You can fix this by moving the "if not line" after the rstrip() call. I also recommend calling writer.close(). Also, the call to async() is not necessary (it's implied by run_until_complete()). On Sat, Feb 8, 2014 at 2:28 PM, Victor Stinner <victor.stin...@gmail.com>wrote: > Hi, > > When I use the "stream" API for sockets and subprocesses, it's unclear > to me when the socket is closed and when the process is terminated. > > Example using open_connection(): > http://docs.python.org/dev/library/asyncio-stream.html#example > > The socket is not explicitly closed. When will the socket be closed? > At the end of the print_http_headers() coroutine? When the last > reference to the transport is deleted? > > Does writer.close() close the socket or not? Maybe only the write end? > > Same question for subprocesses: if I create a subprocess with pipes, > when are these pipes closed? Is there a recommanded way to close them > explicitly? > > Victor > -- --Guido van Rossum (python.org/~guido)
