[issue32561] Add API to io objects for non-blocking reads/writes

Nathaniel Smith added the comment: The proposal is to be able to run io module operations in two modes: the regular one, and one where performing actual I/O is forbidden – so if they go down the stack and can fulfill the operation from some in-memory buffer, great, they do that, and if not,

[issue32561] Add API to io objects for non-blocking reads/writes

STINNER Victor added the comment: I suggest to close the issue and move the discussion to a place to discuss asynchronous ideas. I'm sorry, but I don't understand what it is proposed here. I understand that Nathaniel wants to add something like a new "asynchronous" mode in the io module

[issue32561] Add API to io objects for non-blocking reads/writes

STINNER Victor added the comment: The Linux kernel 5.1 also got a new "io_uring" for asynchronous I/O: "Ringing in a new asynchronous I/O API" https://lwn.net/Articles/776703/ Linux 5.2: "The io_uring mechanism has a new operation, IORING_OP_SYNC_FILE_RANGE, which performs the equivalent of

[issue32561] Add API to io objects for non-blocking reads/writes

STINNER Victor added the comment: > Background: Doing I/O to files on disk has a hugely bimodal latency. If the > I/O happens to be in or going to cache (either user-space cache, like in > io.BufferedIOBase, or the OS's page cache), then the operation returns > instantly (~1 µs) without

[issue32561] Add API to io objects for non-blocking reads/writes

Giampaolo Rodola' added the comment: Gotcha. Thanks for clarifying. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue32561] Add API to io objects for non-blocking reads/writes

Nathaniel Smith added the comment: The idea here is *not* to avoid using a thread pool in general. When the data is on disk, using a thread pool is (a) unavoidable, because of how operating system kernels are written, and (b) basically fine anyway, because the overhead added by threads is

[issue32561] Add API to io objects for non-blocking reads/writes

Giampaolo Rodola' added the comment: os.preadv() and os.pwritev() are great but to my understanding one essential piece is still missing in order to effectively do non-blocking file IO and avoid using a thread pool: being notified when the file fd is readable/writable. select() and epoll()

[issue32561] Add API to io objects for non-blocking reads/writes

YoSTEALTH added the comment: There will be lot of confusion using "buffered" & "unbuffered" terminology, since python already has BufferedIOBase (as mentioned by Martin). It would be more appropriate to create io.CachedIOBase and add non-blocking argument to

[issue32561] Add API to io objects for non-blocking reads/writes

Antoine Pitrou added the comment: > Do you think we can deprecate the existing broken non-blocking mode? I would suggest asking on python-dev. I wouldn't mind it, but perhaps there are people using it. -- ___ Python tracker

[issue32561] Add API to io objects for non-blocking reads/writes

Nathaniel Smith added the comment: That's a reasonable concern. Do you think we can deprecate the existing broken non-blocking mode? -- ___ Python tracker

[issue32561] Add API to io objects for non-blocking reads/writes

Antoine Pitrou added the comment: > And all the async file IO APIs I know [1][2][3] have the public API of "just > like regular files, but the blocking methods are async". 99% of the time, > that means TextWrapper and BufferedStream. So I just don't see any way to get > the

[issue32561] Add API to io objects for non-blocking reads/writes

Nathaniel Smith added the comment: Hmm, why did I use "unbuffered" as my term above? That's a very odd name. It's like, exactly the opposite of what we actually want. Clearly I did not think this through properly. Please pretend I said "buffer-only" instead, thanks. > So my

[issue32561] Add API to io objects for non-blocking reads/writes

Antoine Pitrou added the comment: > Ideally we would be able to do buffer-only reads through all the of the > different read methods (read, readline, readinto, ...), Hmm... We already have non-blocking support in BufferedIOReader, except it *doesn't work*. The problem is,

[issue32561] Add API to io objects for non-blocking reads/writes

Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker ___ ___

[issue32561] Add API to io objects for non-blocking reads/writes

Nathaniel Smith added the comment: > BufferedIOBase is an abstract class and, despite the name, doesn’t > necessitate a buffer or cache Right, sorry, skimmed too fast. > In Issue 32475 there is a proposal to add a “getbuffn” method returning the > amount of unread pending

[issue32561] Add API to io objects for non-blocking reads/writes

Change by Martin Panter : -- dependencies: +Add ability to query number of buffered bytes available on buffered I/O ___ Python tracker

[issue32561] Add API to io objects for non-blocking reads/writes

Martin Panter added the comment: BufferedIOBase is an abstract class and, despite the name, doesn’t necessitate a buffer or cache. Adding methods and properties might break compatibility with third-party implementations, or get ugly with optional methods and multiple

[issue32561] Add API to io objects for non-blocking reads/writes

New submission from Nathaniel Smith : Background: Doing I/O to files on disk has a hugely bimodal latency. If the I/O happens to be in or going to cache (either user-space cache, like in io.BufferedIOBase, or the OS's page cache), then the operation returns instantly (~1 µs)