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 yselivanov
Recipients martin.panter, python-dev, vstinner, yselivanov
Date 2016-10-18.23:22:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1476832966.36.0.992303366419.issue26685@psf.upfronthosting.co.za>
In-reply-to
Content
IOW, what is happening in uvloop:

1. A user has a Python socket object and passes it asyncio (run with uvloop) API.

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 vanilla asyncio.

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.
History
Date User Action Args
2016-10-18 23:22:46yselivanovsetrecipients: + yselivanov, vstinner, python-dev, martin.panter
2016-10-18 23:22:46yselivanovsetmessageid: <1476832966.36.0.992303366419.issue26685@psf.upfronthosting.co.za>
2016-10-18 23:22:46yselivanovlinkissue26685 messages
2016-10-18 23:22:46yselivanovcreate