What exactly is "overlapped" I/O

[Andrew Falanga]

Hi,

I'm writing a Windows Sockets based program and coming from the UNIX
world there is much in there that is confusing. However, for the
purposes of this posting what, exactly, is "overlapped" I/O? I'm
seeing in the example code for WSARecvFrom the use of the
WSAOVERLAPPED structure but the example code doesn't actually do
anything with it other than simply use it in the call to WSARecvFrom.
Is it necessary to include this structure even though the code doesn't
do anything with it?

Thanks,
Andy

[d***@csclub.uwaterloo.ca.invalid]

Post by Andrew Falanga
Hi,
I'm writing a Windows Sockets based program and coming from the UNIX
world there is much in there that is confusing. However, for the
purposes of this posting what, exactly, is "overlapped" I/O? I'm
seeing in the example code for WSARecvFrom the use of the
WSAOVERLAPPED structure but the example code doesn't actually do
anything with it other than simply use it in the call to WSARecvFrom.
Is it necessary to include this structure even though the code doesn't
do anything with it?

You can safely ignore it, and I believe it's safe to use a null pointer
instead of actually giving it a WSAOVERLAPPED (but check the
documentation to be sure).

(If you call WSARecvFrom just right, it will return immediately,
complete the I/O operation in the background, and set a synchronization
handle (which you can wait for) when it's done; the WSAOVERLAPPED
structure contains the bookkeeping information needed to keep track of
that.)


dave

[Charlie Gibbs]

In article

Post by Andrew Falanga
Hi,
I'm writing a Windows Sockets based program and coming from the UNIX
world there is much in there that is confusing. However, for the
purposes of this posting what, exactly, is "overlapped" I/O? I'm
seeing in the example code for WSARecvFrom the use of the
WSAOVERLAPPED structure but the example code doesn't actually
do anything with it other than simply use it in the call to
WSARecvFrom. Is it necessary to include this structure even
though the code doesn't do anything with it?

You can safely ignore it, and I believe it's safe to use a null
pointer instead of actually giving it a WSAOVERLAPPED (but check
the documentation to be sure).
(If you call WSARecvFrom just right, it will return immediately,
complete the I/O operation in the background, and set a
synchronization handle (which you can wait for) when it's
done; the WSAOVERLAPPED structure contains the bookkeeping
information needed to keep track of that.)

I have yet to use overlapped I/O for anything, including serial
port I/O; it sounds like a lot of unnecessary complexity to me.
In fact, with only a couple of minor exceptions you can write
Windows socket-based programs exactly the way you would write
Unix programs - including using recv() or recvfrom() in place
of their Windows-specific counterparts. There's a little bit of
difference when handling non-blocking sockets (use WSAAsyncSelect()
instead of fcntl() to set the socket non-blocking, and you can use
the Windows message loop in place of select()). And, of course,
you must call WSAStartup() before doing anything.

But with a couple of tweaks from the preprocessor, writing socket
code that compiles under either Windows or Unix is quite easy to do.

[Ulrich Eckhardt]

Post by Charlie Gibbs
I have yet to use overlapped I/O for anything, including serial
port I/O; it sounds like a lot of unnecessary complexity to me.

Just a hint where things like that can come in handy: numbercrunching.
Imagine a program reading a sequence of numbers on stdin, performing prime
factorization (is that the correct term?) on them and then writing the
prime factors to stdout. In the most primitive form, this program will

1. read one number
2. compute prime factors
3. write one number
4. go to 1.

Using overlapped IO it will become

1. start reading one number
2. wait for reading one number to finish
3. start reading next number
4. compute prime factors
5. start writing one number
6. go to 2
finally: wait for all writes to finish

(Sorry, the example is actually ugly, but I hope the point comes across.)

The difference is that at the same time the input system, the output system
and the numbercrunching system (CPU) can be active, one of them even always
100%. In the first case, the control structures are always either waiting
for input, waiting for output or waiting for the CPU.

Note: you can achieve the same using threads, though that might be even more
complicated. Further, the effects are also affected by various degrees of
buffering during IO.

Post by Charlie Gibbs
In fact, with only a couple of minor exceptions you can write
Windows socket-based programs exactly the way you would write
Unix programs - including using recv() or recvfrom() in place
of their Windows-specific counterparts. There's a little bit of
difference when handling non-blocking sockets (use WSAAsyncSelect()
instead of fcntl() to set the socket non-blocking, and you can use
the Windows message loop in place of select()).

Full ACK.

Post by Charlie Gibbs
But with a couple of tweaks from the preprocessor, writing socket
code that compiles under either Windows or Unix is quite easy to do.

I'm not sure I would want to miss the ability to WaitForMultipleObjects on
some socket handles for IO and an event for e.g. terminating. Doing that
with POSIX select() and a dummy socket seems a bit clumsy to me.

Uli

[Jerry Coffin]

In article <glpn25-***@satorlaser.homedns.org>,
***@satorlaser.com says...

[ ... ]

Post by Ulrich Eckhardt
1. read one number
2. compute prime factors
3. write one number
4. go to 1.

Actually, step 3 should be something like "write prime factors" --
unless the number is prime, there will be more than one.

Unless your factoring a lot of small numbers, this isn't a very good
example though. Overlapped I/O doesn't gain you much when you spend 10
milliseconds reading a number, then spend an hour or two factoring that
number...

Overlapped I/O tends to be at its most useful when the process is
usually I/O bound, but you're dealing with two or more I/O devices. For
example, if you're copying a file from one disk to another, the easy way
is to read one buffer-full of data from one, then write it to the other.
The time taken is the time to read the file plus the time to write the
file.

Using overlapped I/O, you start by reading a buffer-full of data. As
soon as that completes you read initiate reading of another buffer-full
of data, and also initiate writing of the first buffer-full of data. If
the file is large, you spend most of the time reading from one disk AND
writing to the other. The time taken is (roughly) the time to either
read or write the file, whichever is slower. Assuming reading and
writing take about the same time, you've roughly doubled the overall
speed.

[d***@csclub.uwaterloo.ca.invalid]

Post by Ulrich Eckhardt

Post by Charlie Gibbs
In fact, with only a couple of minor exceptions you can write
Windows socket-based programs exactly the way you would write
Unix programs - including using recv() or recvfrom() in place
of their Windows-specific counterparts. There's a little bit of
difference when handling non-blocking sockets (use WSAAsyncSelect()
instead of fcntl() to set the socket non-blocking, and you can use
the Windows message loop in place of select()).

Full ACK.

Post by Charlie Gibbs
But with a couple of tweaks from the preprocessor, writing socket
code that compiles under either Windows or Unix is quite easy to do.

I'm not sure I would want to miss the ability to WaitForMultipleObjects on
some socket handles for IO and an event for e.g. terminating. Doing that
with POSIX select() and a dummy socket seems a bit clumsy to me.

With Winsock sockets you're probably better off creating a hidden
window (or even one per socket), using WSAAsyncSelect, and doing
MsgWaitForMultipleObjects. If you have a multi-I/O wait loop that
needs to talk to anything other than a socket (like a serial port),
though, you can't use WSAAsyncSelect for that, and overlapped I/O is
convenient there (especially for writes that could block; I believe if
you're only reading you can just wait on the file HANDLE).

In POSIX, the usual model has everything coming into your program from
the outside world being either a signal or something coming through a
select()able file descriptor. The return value of select() tells you
which one of those it is, so you can handle it appropriately; if it's
something generated by processing internal to your program, you won't
be in a blocking select() call. (If you have processing to do and need
to select, you'll give it a non-infinite timeout, and timed-out-
nothing-ready is also a distinct return status.) There's no need in
this model to have a synchronization object to indicate that it's time
to exit.
(Note the absence of threads in this model; process creation and IPC
(using pipes or sockets) is cheap enough that it's often not needed.
If you need both true concurrency and shared memory, then you really do
want threads, but this sort of synchronization will be the least of
your worries.)


dave

[Alex Mizrahi]

AF> I'm writing a Windows Sockets based program and coming from the UNIX
AF> world there is much in there that is confusing. However, for the
AF> purposes of this posting what, exactly, is "overlapped" I/O?

that's asynchronous, non-blocking I/O. in the OVERLAPPED structure you can
see Event (synchronization object) used for synchronization, however there
are other possibilities too.