Forcing WSARecv to overlap

Question

I'm triying to implement a server which uses IOCompletionPort to read from its clients. I have something very similar to this example.

If I understand correctly, this should be my design:

1. [Main Thread] Create a listen socket, bind and listen
2. [Main Thread] Create an event and attach it to the socket accept signal using WSAEventSelect
3. [Accept Thread] Wait for the event and accept a client
4. [Accept Thread] When a client connects, use CreateIOCompletionPort to use the IOCompletion queue with it
5. [Accept Thread] The accept thread calls the first WSARecv with overlap parameters
6. [Worker Threads] Use the queue to implement a leader-follower pattern on WSARecv

After some reading on WSARecv (Here) I discovered that WSARecv might return immediately with the data if the data is ready. That seems kinda weird because that means that a worker could loop on WSARecv without returning to the IO queue if the client sends fast enough - And that could cause client starvation...

Hereby my questions are:

1. Is there a way to "force" WSARecv to not returning immediately? I mean, to return IO_PENDING 100% of the time?
2. If not - What would be the correct design, optimized for scalability?

This is how I use WSARecv:

flags = 0;
receiveResult = WSARecv(clientSocket, &(olStruct->Buffer), 1, &bytesReceived, &flags, (OVERLAPPED*)olStruct, NULL);

olStruct is an extension for the OVERLAPPED struct.

EDIT: I ended up reposting what I got from WSARecv using PostQueuedCompletionStatus. I'd love to hear other solutions though See Answer

Answer 1

It seems that when WSARecv completes immediately it returns the buffer AND posts to the IOCompletionPort queue.

So the current design still stands.

Answer 2

If you have associated your handle with a completion port, WSARecv() returning immediately with success is semantically equivalent for you to WSARecv() returning with pending, unless you have:

• set completion port bypass on success, as described in SetFileCompletionNotificationModes, or
• you are providing a valid HANDLE with a bit set, as described in GetQueuedCompletionStatus for hEvent member