Windows Sockets：封鎖
本文和兩個方針手冊說明了 Windows Sockets 程式設計的幾個問題。 本文包含封鎖問題。 文章涵蓋其他問題： Windows 通訊端：位元組排序 和 Windows 通訊端：轉換字串 。
如果您使用或衍生自 CAsyncSocket 類別 ，您必須自行管理這些問題。 如果您使用或衍生自類別 CSocket，MFC 會為您管理它們。
封鎖
通訊端可以處於「封鎖模式」或「非封鎖模式」。封鎖模式中通訊端的函式在完成動作之前不會傳回。 之所以將這種情形稱為封鎖，是因為函式呼叫的通訊端在呼叫傳回之前無法執行任何動作 (即遭到封鎖)。 例如，對成員函式的 Receive 呼叫可能需要很長的時間才能完成，因為它會等候傳送應用程式傳送（如果您使用的是 CSocket ，或搭配封鎖使用 CAsyncSocket 則為 ）。 CAsyncSocket如果物件處於非封鎖模式（以非同步方式運作），則呼叫會立即傳回，而目前的錯誤碼可透過 GetLastError 成員函式擷取，則為 WSAEWOULDBLOCK ，表示呼叫會因為模式而立即遭到封鎖。 （ CSocket 永遠不會傳 回 WSAEWOULDBLOCK 。類別會為您管理封鎖。
32 位元和 64 位元作業系統 (例如 Windows 95 或 Windows 98) 下的通訊端行為與 16 位元作業系統 (例如 Windows 3.1) 下的通訊端行為不同。 和 16 位元作業系統不同的是，32 位元與 64 位元作業系統使用先佔式多工作業，並提供多執行緒。 在 32 位元和 64 位元作業系統下，您可以將通訊端放在不同的背景工作執行緒中。 您可以封鎖執行緒中的某個通訊端，而不會影響應用程式中的其他活動，而且不需花費計算時間在封鎖上。 如需多執行緒程式設計的詳細資訊，請參閱多執行緒一 文 。
注意
在多執行緒應用程式中，您可以使用 CSocket 的封鎖性質來簡化您程式的設計，而不會影響使用者介面的回應性。 藉由在主執行緒中處理使用者互動，並在其他執行緒中處理 CSocket，您可以將這些邏輯作業分離。 在未採用多執行緒的應用程式中，這兩種活動必須合併並視為單一執行緒來處理，這通常表示使用 CAsyncSocket 時，您可以視需要處理通訊要求，或覆寫 CSocket::OnMessagePending 以便在長時間的同步處理活動期間處理使用者動作。
其餘的討論適用於以 16 位元作業系統為目標的程式設計人員：
通常，如果您使用 CAsyncSocket，則應該避免使用封鎖作業，而改用非同步作業。 在非同步作業中，從呼叫 之後收到 WSAEWOULDBLOCK 錯誤碼的點，例如，您會等 OnReceive 到呼叫成員函式，通知您可以再次 Receive 讀取。 非同步呼叫是透過呼叫通訊端的適當回呼通知函式來進行，例如 OnReceive 。
在視窗中不建議採用封鎖呼叫。 根據預設， CAsyncSocket 支援非同步呼叫，而且您必須使用回呼通知自行管理封鎖。 另一方面，CSocket 類別 是同步的。 它會提取 Windows 訊息並為您管理封鎖。
如需封鎖的詳細資訊，請參閱 Windows Sockets 規格。 如需「開啟」函式的詳細資訊，請參閱 Windows 通訊端：通訊端通知 和 Windows 通訊端：衍生自通訊端類別 。
如需詳細資訊，請參閱