|
的缺省行为是阻塞方式的，除非程序员显式地请求该操作为非阻塞方式。我们强烈推荐程序员在尽可能的情况下使用非阻塞方式（异步方式）的操作。因为非阻塞方式的操作能够更好地在非占先的Windows环境下工作。程序员应该在绝对必要的时候才采用阻塞方式。而且在你必须使用阻塞方式的操作前仔细阅读并理解这一部分。
即使在阻塞方式下，有些操作（例如bind(),getsockopt(),getpeername()）也会立刻完成。对于这些操作，阻塞方式和非阻塞方式并没有什么两样。其他一些操作（例如recv()）可能立刻完成，也可能需要阻塞一段随机的时间才能完成。这都取决于不同的传输情况。当用于阻塞套接口时，这些操作被认为是工作于阻塞方式的，所有会阻塞的例程在以前或以后的列表中都打上了星号作标记。
在Windows Sockets实现中，一个无法立刻完成的阻塞操作是按如下方式处理的。DLL先初始化操作，然后进入一个循环，在循环中发送收到的任何信息－为了使在必要时把处理器交给其他线程，然后检查Windows Sockets功能是否完成。如果功能完成了，或者WSACancelBlockingCall()被唤起，阻塞操作以一个适当的返回值结束。完整的关于这种机制的描述，请参见5.3.13节，WSASetBlockingHook()，这一部分还包括了对于各种函数伪代码的讨论。
如果一个正在运行某一阻塞操作的进程收到了一个Windows消息，那么应用程序有可能试图发出另一个Windows Sockets调用，由于很难安全地处理这种情形，Windows Sockets规范不支持这种应用程序的工作方式。在这种情况下，有两个函数可以帮助程序员。WSAIsBlocking()可以用来确定在该进程上是否有阻塞的Windows Sockets调用。WSACancelBlookingCall()可以用来取消在线的阻塞调用，如果有的话。任何其他的Windows Sockets函数如果在这种情况下被调用，则会失败并返回错误代码WSAEINPROGRESS。要强调的是，这一限制适用于所有阻塞和非阻塞的 |