Why is asynchronous IO preferred

Question

So I've been doing some WIN32 socket programming and I'm trying to understand why Overlapped IO is preferred. In particular, I'm wondering why something like this

if (WSARecv(
            socket,
            dataBuf,
            1,
            NULL,
            &flags,
            &ov,
            NULL)
            == SOCKET_ERROR) {
    if (WSAGetLastError() == WSA_IO_PENDING)
    {
        if (WSAWaitForMultipleEvents(1, &ov.hEvent, FALSE, INFINITE, FALSE) == WAIT_TIMEOUT)
        {
            return FALSE;
        }
    } else {
        return FALSE;
    }
}
// ... more code here
return TRUE;

Is preferred over a normal IO call like this

 recv(socket, dataBuf, bufLen), 0);

From my understanding, the first call will block if the IO event didn't complete at the WSAWaitForMultipleEvents, whereas the second call blocks directly on recv until data has arrived. So what is the actual benefit of having the IO call block slightly later? Is it that IF you had something you could do before waiting you'd do that?

If that is the case is Overlapped IO worth it/needed in applications in which you have can't do anything until data has arrived?

score 4 · Accepted Answer · answered Aug 22 '16 at 02:23

4

The case you show is not the typical reason to use any kind of asynchronous I/O, quite the opposite I would say (since it is, as you noted, not really asynchronous anyway).

The typical reason to use asynchronous I/O is just because it is asynchronous, your program can continue with doing something else instead of waiting for the I/O operation to finish.

answered Aug 22 '16 at 02:23

Some programmer dude

400,186
35
402
621

Could you give an example of something that can be done while waiting for data? – FrozenHawk Aug 22 '16 at 03:02
3

The canonical example is an application that has more than one active socket, e.g., a server. You can either have one thread for each client, which is simple but scales poorly, or you can use asynchronous I/O. – Harry Johnston Aug 22 '16 at 03:42
3

I would have thought the canonical application is any GUI application at all, that needs to keep responding to user input and system redraw calls lest it become ... unresponsive. – Chris Becke Aug 22 '16 at 06:06

score 1 · Answer 2 · answered Aug 22 '16 at 08:05

Asynchronous I/O save thread resources.

In particular, whenever you process some client requests through synchronous I/O, you allocate 1 thread for it. Which works fine when you have 1 client. Or 10 clients.

If you have 10000 clients, you would have to create 10K threads for them to serve them. Which is possible, but inefficient in many cases.

Using asynchronous I/O allows to handle very large number of clients in one thread (particular number depends on OS/architecture). Usually such approach can be just a bit slower that the dedicated thread for a small number of clients (as request handling is serialized), but much better throughput in other case.

You are really talking about [I/O Completion Ports](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365198.aspx) here. Using asynchronous I/O alone won't use system resources efficiently. — IInspectable, Aug 22 '16 at 09:30

Why is asynchronous IO preferred

2 Answers2