Принудительное перекрытие WSARecv

Я пытаюсь реализовать сервер, который использует IOCompletionPort для чтения от своих клиентов.
У меня есть что-то очень похожее на этот пример.

Если я правильно понимаю, это должен быть мой дизайн:

1. [Основной поток] Создать сокет прослушивания, связывание и прослушивание
2. [Основной поток] Создать событие и прикрепить его к сигналу принятия сокета с помощью WSAEventSelect
3. [Accept Thread] Дождаться события и принять клиента
4. [Принять поток] Когда клиент подключается, используйте CreateIOCompletionPort для использования с ним очереди IOCompletion
5. [Accept Thread] Принимающий поток вызывает первый WSARecv с параметрами перекрытия
6. [Рабочие потоки] Используйте очередь для реализации шаблона лидера-последователя в WSARecv.

После прочтения на WSARecv (Вот) Я обнаружил, что WSARecv может немедленно вернуться с данными, если они готовы. Это кажется странным, потому что это означает, что рабочий может зацикливаться на WSARecv, не возвращаясь в очередь ввода-вывода, если клиент отправляет достаточно быстро — и это может вызвать голодание клиента …

Настоящие вопросы:

1. Есть ли способ «заставить» WSARecv не возвращаться немедленно? Я имею в виду, чтобы вернуть IO_PENDING 100% времени?
2. Если нет — какой будет правильный дизайн, оптимизированный для масштабируемости?

Вот как я использую WSARecv:

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

olStruct является расширением для структуры OVERLAPPED.

РЕДАКТИРОВАТЬ:
Я закончил репостить то, что я получил от WSARecv, используя PostQueuedCompletionStatus. Хотелось бы услышать другие решения, хотя
Смотрите ответ