視窗和線程漫談

標籤：視窗   線程   

為什麼要討論視窗和線程

討論這個依然是跟之前的項目經曆有關。這裡暫且稱該項目為 A 項目。A 項目包括一個用戶端和服務端，用戶端有一個核心的網路模組，該網路模組基於完成連接埠開發，有多個背景工作執行緒，網路模組負責接收來自服務端的資料，對這些資料進行處理，並將最終的處理結果顯示在視窗上。那麼問題來了，背景工作執行緒如何將資料的最終處理結果顯示在視窗上？可以說這個問題不僅僅是 A 項目中遇到的問題，絕大多數網路應用程式都會遇到這個問題。當時 A 項目中採用的方案是在背景工作執行緒中利用視窗控制代碼直接調用相應函數（如 SendMessage）對視窗進行操作。雖然這種做法當時並沒有出現問題？但它真的沒問題嗎？如果有問題，我們該採用什麼方式將最終的處理結果顯示在視窗上呢？

視窗和線程的關係

理論知識是我們回答上述問題的基礎。這方面我找到的唯一資料就是 《Windows 核心編程》 第 26 章 視窗訊息。對這塊不太明白的兄弟，可以先看下。這裡我們就不詳述了。

在背景工作執行緒中利用視窗控制代碼直接調用相應函數對視窗進行操作這種做法有沒有問題

絕大多數情況下，確實不會出現問題。但只是絕大多數情況下，下面是出現問題的兩種情況。

1. 這種情況是我在項目 A 中親身經曆的。當時我在背景工作執行緒中調用了 SetFocus 這個函數，結果這個函數並沒有成功返回，為什嗎？下面是 SetFocus 文檔中的描述。

   Sets the keyboard focus to the specified window. The window must be attached to the calling thread’s message queue.

   原因很明顯，傳遞給 SetFocus 函數的視窗控制代碼代表的視窗必須是屬於調用 SetFocus 函數的這個線程的，但背景工作執行緒並沒擁有該視窗，也沒有擁有任何視窗。那為什麼調用 SetFoucs 函數要有這個需求呢？這個只能說我也不太清楚，但結合 《Windows 核心編程》 第 26 章 中的相關描述，每一個線程都擁有自己的鍵盤焦點，應該在一定程度上回答了這個問題。

2. 這種情況是《多線程編程中的主介面安全處理》這篇文章中提到的，大致情況就是擁有視窗的線程正在等待背景工作執行緒退出，而背景工作執行緒正阻塞於對視窗的 SendMessage 調用中。應該說，這種情況不是沒有可能發生。

說了這麼多，說到底我是不建議在背景工作執行緒中利用視窗控制代碼直接調用相關函數對視窗進程操作這種做法的，雖然這種做法絕大多數情況下不會出錯，但一旦出現問題，排查起來就比較困難。但我也不完全否認這種做法，前提是，程式員自身一定要對程式本身的邏輯認識清楚，比如在背景工作執行緒中會不會調用類似 SetFocus 的這類函數，會不會出現上面提到的第二種情況。

背景工作執行緒如何將最終的處理結果顯示到視窗

既然，在背景工作執行緒中通過視窗控制代碼直接調用相關函數對視窗進行操作的這種做法不太好，那採用什麼方法將最終的處理結果顯示到視窗上呢？我的方法是調用 PostMessage，通過自訂訊息將資料交給視窗的視窗過程處理，也就是擁有視窗的線程處理，這種情況下背景工作執行緒中唯一和視窗相關的操作就是通過視窗控制代碼調用 PostMessage。目前，我並想不到這種做法有什麼有問題的地方，如果有人覺得有問題，大家可以一起討論下。

另外，如果有兄弟知道更好的做法，大家也可以討論下。

感受和思考

在尋找線程和視窗的相關資料過程中，發現很多人都在問關於線程和視窗的一些問題，在討論關於視窗和線程的一些概念，而且搞出來一些很玄乎的東西。但其實搞清楚一些基礎知識，自己獨立思考一下，這些問題並不難回答。也許 MFC 相對傳統的 Win32 API 確實方便些，但視窗過程，訊息迴圈等一些基本概念還是要理解的。

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。

視窗和線程漫談