Talk:Asynchronous I/O

message: * Non-blocking refers to using normal I/O primitives in non-blocking mode, e.g. the O_NONBLOCK flag to open(2), where calls to read(2) and write(2) return -1 with errno set to EAGAIN if I/O would block.
* Asynchronous refers to separating checks for the availability of I/O, potentially on many fds, and actually doing the I/O. For example, one may use the O_ASYNC flag to open(2), wait for the kernel to send SIGIO, and then use non-blocking calls to actually do the I/O; or call select(2) with a set of fds to wait for I/O to become available on one of them, then use read(2) and write(2) to do I/O on any fds which have data waiting.
:In fact, they are completely different things: nonblocking-I/O is completely synchronous: data is only being transferred to the application doing the I/O during the I/O call, while with asynchronous I/O, the data is actually transferred while the application does other things. For example, boost asio doesn't do any asynchronous I/O, its fully synchronous (one has to call a asio function to actually do the I/O), while overlapped I/O under e.g. windows is indeed fully asynchronous: the function returns immediately and the buffer is filled asynchronously. This is even more important as, programmatically, asynchronous I/O needs very different program structures and usage than non-blocking I/O.
::No, during a non-blocking I/O call the data is being transferred to/from an OS buffer.  I fail to see how this differs from an asynchronous callback executed when a buffer is full/empty. EdC 23:26, 25 October 2007 (UTC)
replies: text: That's how the terms are used in C/POSIX. I suspect that some other culture (probably Java?) calls (emulated) asynchronous IO "non-blocking IO" and thus the confusion. Any Java programmers who can enlighten us? --Doc aberdeen 14:13, 27 February 2007 (UTC)

text: That's not true: In fact, non-blocking I/O with a select loop allows for zero-copy implementations and for multiple I/O events to be processed simultaneously by multiple threads: One can open a number of fds with O_DIRECT for zero-copy and, once select returns, delegate processing to other threads. This is asynchronous and involves parallelity of multiple I/Os. But, it's not the usual way using select.  -- Juergen 91.52.170.222 (talk) 20:08, 22 March 2010 (UTC)
replies: text:  You (and many others here) confuse asynchronous I/O done e.g. in the kernel with I/O done in an application. OS Kernels almost always do all I/O asynchronously, but that doesn't mean that the userspace I/O is asynchronous (for example, disk I/O is always asynchronous in GNU/Linux, but will happily block your app for ages). This article should either get the distinction right, or it will simply be wrong and useless forever.109.193.183.13 (talk) 12:26, 28 August 2014 (UTC)
thread_title: Asynchronous vs. Non-blocking

message: I am unsure of other operating systems, but on Microsoft Windows platforms, completion routines for a particular file descriptor are not stacked making uncontrolled stack growth impossible.  This is clearly documented in the MSDN.  See FileIOCompletionRoutine, WSARecv, etc.  Does this problem exist with other OSes (I suspect that this is not the case) or is this just wrong?
Karl McClendon (talk) 18:41, 10 November 2009 (UTC)
replies: text: Classic Mac OS was known to have an uncontrolled stack growth problem on its completion routines. ISC PB (talk) 23:42, 6 March 2024 (UTC)
thread_title:  Uncontrolled stack growth in question 

message: Asynchronous reading is, at least with linux, also possible with memory mapped file I/O, combined with prefetching by madvice (MADV_WILLNEED), which works without the overhead of copying and with less system calls.
* Am I allowed to add this to the article, without being reverted for citing no references ?
* Are there other OSs with that same capabilities ?
-- Juergen 91.52.170.222 (talk) 20:08, 22 March 2010 (UTC)
replies: text: This is actually wrong - madvise doesn't guarantee that an access will be non-blocking or asynchronous (neither on return, nor at any later time) - if the data is in the cache at access time, it might be, otherwise it won't be. madvise can't ensure that data is in the cache at a later time, and doesn't even attempt to (e.g. on GNU/Linux). Besides, every page fault is a system call, so whether there are actual savings on system calls with this technique is not shown.109.193.183.13 (talk) 12:30, 28 August 2014 (UTC)
replies: text: Agreed.  Asynchronicity is all about wait control.  If you take a page fault while accessing data you think you already have, and go away for an indefinite time until the page is delivered, you are stuck waiting in the kernel, and your application is not running.  In other words, not asynchronous at all.  Telling the kernel that you would like access to a memory-mapped file ASAP makes no guarantees about when the data will actually be available.  True asynchronous I/O facilities will tell you when the data is (or will be with no inordinate delays) available. ISC PB (talk) 00:07, 7 March 2024 (UTC)
thread_title:  mmap and madvise 

message: Shouldn't we differentiate between these types of asynchronity for the article:
* the one between device and OS (which is common with all modern OSs, implemented by interrupts, but not usually called asynchronous I/O unless combined with one of the following approaches in the application),
* the one between OS and application (which needs a particular approach, e.g., threads, SIGIO, select, O_NONBLOCK, mmap with madvise, etc.), and
* O_DIRECT, bypassing the OS buffers, still using asynchronous interrupts, but to be combined with one of the above application approaches to usually be called asynchronous ?
This wikipedia article calls the first type asynchronous, which is acceptable, the IBM article does not, which is acceptable, too, but contradicts to the article's point of view.
Different contributors have different positions here. How can we manage to get a consistent one ?
-- Juergen 91.52.170.222 (talk) 20:08, 22 March 2010 (UTC)
replies: text: IMHO, O_DIRECT has nothing to do with asynchronicity, and shouldn't be even mentioned here. ISC PB (talk) 23:57, 6 March 2024 (UTC)
thread_title:  Mixing different levels of asynchronity 

message: This really bothers me: "All forms of asynchronous I/O open applications up to potential resource conflicts and associated failure. Careful programming (often using mutual exclusion, semaphores, etc.) is required to prevent this." Sure, I suppose that's the case sometimes. But in my experience, most actual uses of async IO are selected to *avoid* this sort of stuff. When you have only one thread that does stuff, then eventually returns to the top of a runloop and does select(), there's little reason to lock anything, since there's no other thread to lock against.
I'm also wondering what the "processes" section is all about. In what way are "processes" a form of async IO? Isn't async IO all about eliminating the need for one process per IO stream? 69.14.204.77 (talk) 12:45, 8 January 2013 (UTC)
replies: text: From the point of view of the Application.  Consider the ancient "cu" program.  (Or the newer "screen"?)  Keyboard-to-serial and serial-to-screen flows operated in parallel, asynchronous to each other.  In primordial Unix, the only way this could be made to work was by them being separate processes. ISC PB (talk) 23:52, 6 March 2024 (UTC)
thread_title:  Forms 

message: The missing citation might be due to the fact that there is nothing to compare with. I mean: "Processes are fairly expensive to create and maintain", with respect to what? Was an old statement? Also because the other items in the list are: Polling, select, signals and callbacks.. plus some more. i.e. totally different approaches. They might make clear why processes are "heavy" but yet instead of a citation I would describe it.  — Preceding unsigned comment added by 84.75.169.43 (talk) 20:12, 2 March 2016 (UTC)
thread_title:  Processes are fairly expensive to create and maintain,[citation needed] 

message: There is a missing description. It starts with: "variations". Variations of what?  — Preceding unsigned comment added by 84.75.169.43 (talk) 20:25, 2 March 2016 (UTC)
thread_title:  Polling 

message: There is a section missing. First a link to the counterpart. Then why and when "a" is better then without "a". Not a chat example, maybe something more ...  — Preceding unsigned comment added by 84.75.169.43 (talk) 20:38, 2 March 2016 (UTC)
thread_title:  Synchronous 

message: Hello fellow Wikipedians,
I have just modified  on Asynchronous I/O. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20101101112358/http://doc.sch130.nsc.ru/www.sysinternals.com/ntw2k/info/comport.shtml to http://doc.sch130.nsc.ru/www.sysinternals.com/ntw2k/info/comport.shtml
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—InternetArchiveBot (Report bug) 23:59, 20 July 2016 (UTC)
thread_title:  External links modified 

message: Hello fellow Wikipedians,
I have just modified one external link on Asynchronous I/O. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive http://www.webcitation.org/6ICibHuyd?url=http://www.kegel.com/c10k.html to http://www.kegel.com/c10k.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 03:41, 11 July 2017 (UTC)
thread_title:  External links modified 

message: There is a difference between asynchronous IO and non-blocking one. With Async IO you first start an operation and you don't know when it will be really completed. Windows e. g. provides Overlapped IO. The system notifies you about IO completion via callback or IOCP. Select, poll and epoll on the other side let you 'read' or 'write' only if there is something to read or kernel buffer is able to store the data you want to write, respectively. Yanpas (talk) 10:35, 10 September 2017 (UTC)
thread_title:  async is not nonblocking 

message: Why does Synchronous I/O redirect here? Shouldn't it have its own page? Or if it is better to discuss them together on the same page then shouldn't that be reflected in the title of this page? AstroMark (talk) 09:13, 7 February 2022 (UTC)
thread_title:  Synchronous I/O Redirect