asyncio icon indicating copy to clipboard operation
asyncio copied to clipboard

[Feature request] Add sendfile support

Open GoogleCodeExporter opened this issue 10 years ago • 4 comments

Should we implement a sendfile 
(http://docs.python.org/3/library/os.html#os.sendfile) support in asyncio?

Original issue reported on code.google.com by [email protected] on 19 Feb 2014 at 1:33

GoogleCodeExporter avatar Apr 10 '15 16:04 GoogleCodeExporter

Check the python-tulip archives. IIRC it's too fragile -- works different on 
different platforms, is broken on some, supports different types of files 
everywhere, etc. etc. Or maybe you end up having to emulate it on some 
platforms but the app would have been better off doing it differently if it had 
known it wasn't supported. Etc. etc.

It has its fans, but let's do this post 3.4. It could be prototyped effectively 
as a 3rd party add-on.

Original comment by [email protected] on 19 Feb 2014 at 2:17

GoogleCodeExporter avatar Apr 10 '15 16:04 GoogleCodeExporter

Python 3.5 added a socket.socket.sendfile() method which uses sendfile() if 
available, or fallback to send().
https://docs.python.org/dev/library/socket.html#socket.socket.sendfile

It looks like sendfile() can be used with non-blocking sockets:
"EAGAIN: Nonblocking I/O has been selected using O_NONBLOCK and the write would 
block."
http://man7.org/linux/man-pages/man2/sendfile.2.html

The method dynamically falls back to send() if sendfile() raises an OSError 
whereas no bytes were copied:

 # We can get here for different reasons, the main
 # one being 'file' is not a regular mmap(2)-like
 # file, in which case we'll fall back on using
 # plain send().

Original comment by [email protected] on 9 Jan 2015 at 4:00

  • Changed title: [Feature request] Add sendfile support

GoogleCodeExporter avatar Apr 10 '15 16:04 GoogleCodeExporter

os.sendfile() does support non-blocking sockets but socket.sendfile() 
explicitly doesn't. If such a feature were to be added it should use plain 
os.sendfile(). Some months ago I started working on this and I remember one 
blocker was the fact that the unit tests for send() which I was using as a 
reference were all using mocks and didn't really test the actual functionality, 
hence I gave up.
It would be great if tulip would grow some kind of functional testing framework 
similar to the one available for the socket module which lets you easily test 
an actual connection (and transfer) between a server and a client.

Original comment by g.rodola on 9 Jan 2015 at 4:24

GoogleCodeExporter avatar Apr 10 '15 16:04 GoogleCodeExporter

Let's use issue 108 to track testing with real sockets, selectors etc.

Original comment by [email protected] on 9 Jan 2015 at 4:29

GoogleCodeExporter avatar Apr 10 '15 16:04 GoogleCodeExporter