Hello, my name is Chad Carlin. I'm a software developer on the Winsock Test Team. Among the many improvements to the Winsock API shipping in Vista is the new WSAPoll function. Its primary purpose is to simplify the porting of a sockets application that currently uses poll() by providing an identical facility in Winsock for managing groups of sockets. Depending on the needs of your application, this addition could be an attractive option.

If you are new to poll, (since just about everyone is new to WSAPoll() ), I'll explain its role in network programming with a brief example. Suppose that you have a server application that is providing a service to several clients concurrently. You would not want your process to be blocked while waiting for a client to send or be able to receive data. You could create a thread per socket, but that would hinder the scalability of your application. By creating an array of structures, each with a member, which is a pointer to one of your sockets, you can poll this array to identify which sockets are guaranteed to be available for reading or writing data. This keeps your server process busy servicing ready clients or other performing useful work.

You should be aware that if you are choosing between using select() and WSAPoll(), that WSAPoll() scales better to a larger number of sockets and can accommodate sockets of different types. If you are creating a large-scale, high-performance Winsock2 application, we recommend that you use the native Winsock overlapped IO facilities.

If you have experience developing applications using poll(), WSAPoll will be very familiar. It is designed to behave just like poll(). In fact, I recently ported the Winsock WSAPoll SDK sample to run on BSD Unix. I know that sounds backwards from what you would expect but, we all like sample code after all. As it turns out it didn't matter which direction I ported. I had really hoped to have some clever insight to give you, or some real handy tip about how to work around some special difference. The truth is, the portions of the code dealing with poll() were unchanged from the sample. Except, of course, for changing the name of the API. Frankly, porting the poll() code went so smoothly, it made converting Windows threads to pthreads seem like the lion's share of the work.

To speed up your porting effort here are some tips:

The minimum set of include files that you'll need are: Winsock2.h, ws2tcpip.h and mstcpip.h. You'll want to switch from using the errno global variable to using the WSAGetLastError() function when looking for extended error codes.

For simplicity, the SDK sample uses macros to fill in the IPv6 address structures to connect or bind to the loopback interface. You should use getaddrinfo() which is the preferred method when writing an IP agnostic application. To support both address types you'll want to switch to using SOCKADDR_STORAGE types instead of sockaddr types used in BSD.

Here is an example of calling WSAPoll on a socket to check if it is writable. If the remote endpoint has accepted the connection, we call send. Get the full sample from the SDK for additional details.

//Call poll for writeability on connecting socket
fdarray.fd = csock;
fdarray.events = POLLWRNORM;
if (SOCKET_ERROR == (ret = WSAPoll(&fdarray, 1, DEFAULT_WAIT )))
if (ret)
    if (fdarray.revents & POLLWRNORM)
        printf("Established connection and signalled POLLWRNORM \n");            
        //Send data
        if (SOCKET_ERROR == (ret = send(csock, TST_MSG, sizeof (TST_MSG),)))
        } else {
            printf("Sent %d bytes@ %d\n",ret, __LINE__);


Listing of networking code samples in the Windows SDK:

Find the latest version of the Platform SDK which includes the sample mentioned above:

MSDN WSAPoll documentation page:

--Chad Carlin