Здравствуйте, acDev, Вы писали:

D>Т.е. могу сразу после вызова WSASend вызывать WSARecv , не дожидаяь при этом уведомления о завершении WSASend?

Да.

D>Понятно. А если я текущий HTTP сервер переделаю так:
D>1) В потоке WorkThread буду читать данные через WSARecv и если требуется "срочный" ответ клиенту, то тут же вызываю WSASend (сейчаз в блокируемом сервере так и зделано).
D>2) Так же имеются "срочные" данные от самого сервера, которые будут тоже отправляться вызовом WSASend (это в отдельном потоке или потоках).

D>Как раз в этой схеме и возможна ситуация с перекрытым вызовом WSASend. Значит, как вы предлагаете, надо организовать очередь для WSASend.
D>Т.е. средует для каждого клиента выделить отдельный буфер для WSASend. А как правильно тогда обслуживать такой буфер, стремясь как можно быстре его "очистить"?

Например, при попытке отправки смотрите, есть-ли незавершённые для данного сокета вызовы WsaSend. Если нет, то просто увеличиваете счётчик отправок и вызываете WsaSend, и при получении уведомления о завершении уменьшаете счётчик. Если есть, то добавляете данные в буфер. При получении уведомления о завершении WsaSend смотрите, есть-ли что-то в буфере, и если есть, то отправляете все данные, благо WsaSend принимает на входе список буферов. Закрыв всё это отдельной для каждого сокета крит. секцией, получите достаточно эффективный, простой и надёжный механизм.