Yury Selivanov added the comment:
IOW, what is happening in uvloop:
1. A user has a Python socket object and passes it asyncio (run with uvloop)
2. uvloop extracts the FD of the socket, and passes it to low-level libuv.
3. At some point of time, libuv closes the FD.
4. When user tries to close the socket, it silently fails in 3.5, and raises an
exception in 3.6.
One way to solve this would be to use os.dup() in uvloop (i.e. pass a
duplicated FD to libuv). But that would mean that programs that use uvloop
will consume file descriptors (limited resource) faster than programs that use
Currently, there's a documented way of creating a socket out of an existing FD
(fourth argument to the socket's constructor). This means that the FD might be
controlled by someone. At least in this case, sock.close() must not raise if
it fails. It's OK if the FD is already close, because the Python socket was
only wrapping it in the first place.
Python tracker <rep...@bugs.python.org>
Python-bugs-list mailing list