深入 CSocket 编程之阻塞和非阻塞模式

核心提示： 阻塞模式下 Server 端与 Client 端之间的通信处于同步状态下，在 Server 端直接实例化 CSocket 类，深入 CSocket 编程之阻塞和非阻塞模式(3)，调用 Create 方法创建 socket ，然后调用方法 Listen 开始侦听，它只是使很少的 socket

阻塞模式下 Server 端与 Client 端之间的通信处于同步状态下。在 Server 端直接实例化 CSocket 类，调用 Create 方法创建 socket ，然后调用方法 Listen 开始侦听，最后用一个 while 循环阻塞调用 Accept 函数用于等待来自 Client 端的连接，如果这个 socket 在主线程（主程序）中运行，这将导致主线程的阻塞。因此，需要创建一个新的线程以运行 socket 服务。

调试跟踪至 CSocket::Accept 函数源码：

while(!Accept(...))
{
　　　　　// The socket is marked as nonblocking and no connections are present to be accepted.
　　if (GetLastError() == WSAEWOULDBLOCK)
　　　PumpMessage(FD_ACCEPT);
　　else
　　　return FALSE;
}

它不断调用 CAsyncSocket::Accept （ CSocket 派生自 CAsyncSocket 类）判断 Server 端 socket 的事件队列中是否存在正在引入的连接事件 - FD_ACCEPT （见 1 ），换句话说，就是判断是否有来自 Client 端 socket 的连接请求。

如果当前 Server 端 socket 的事件队列中存在正在引入的连接事件， Accept 返回一个非 0 值。否则， Accept 返回 0，此时调用 GetLastError 将返回错误代码 WSAEWOULDBLOCK ，表示队列中无任何连接请求。注意到在循环体内有一句代码：

PumpMessage(FD_ACCEPT);

PumpMessage 作为一个消息泵使得 socket window 中的消息能够维持在活动状态。实际跟踪进入 PumpMessage 中，发现这个消息泵与 Accept 函数的调用并不相关，它只是使很少的 socket window 消息（典型的是 WM_PAINT 窗口重绘消息）处于活动状态，而绝大部分的 socket window 消息被阻塞，被阻塞的消息中含有 WM_SOCKET_NOTIFY。