關於 使用中的物件調動器的 介紹

by   mayflowers
首先我們有幾個基本共識，或者說前提條件：
- (1)調度器對使用中的物件的調度（等待等）操作必須是同步完成的。如果調度能夠
非同步完成，調度器就需要被某種機制調度執行，而這正是調度器需要解決的問題。
這是一個矛盾。
- (2)調度器在真正開始調度的時候，必須有至少一個使用中的物件已經發起非同步請求。
否則調度器將永遠陷於等待狀態。
- (3)調度器對象必須在使用之前構造完成。這個比較直觀，我們不討論這個問題。

**啟動部分需要解決的問題（需求）**

這裡以現有的代碼進行描述。

1. 調度器啟動的時候有一個使用中的物件在等待
myAO->IssueAsyncRequest();
CActiveSsheduler::Start();

這是最基本的要求，沒有這個...難以想象啊，嘿嘿。我們構造任何解決方案首先滿
足這個要求。

2. 調度器啟動的時候有兩個使用中的物件在等待
myAO1->IssueAsyncRequest();
myAO2->IssueAsyncRequest();

CActiveSsheduler::Start();

這個要求並不過分，事實上很多應用在啟動調度器之前，都有好幾個使用中的物件用來
處理不同的非同步事件（主要是 observer 之類的東西在等待通知）。

3. 線程的並行問題
無論怎麼設計，整體操作都分為兩個部分：
1. 使用中的物件發起非同步作業
2. 調度器啟動

由於非同步作業的處理通常都在別的線程/進程執行；在步驟 2 之前，使用中的物件請求
的的非同步作業很可能已經完成。架構必須能夠正確的處理這一點。

這一點可以由條件(3)保證。

4. 使用中的物件和調度器之間的依賴應該儘可能的少

**可能的做法**

如果不按照現有的架構，可能有兩種做法：
- 在使用中的物件加入使用中的物件調度器，判斷是否需要啟動調度器
- 在使用中的物件發起第一個非同步請求的時候，判斷是否需要啟動調度器

**第一個方法：加入使用中的物件的時候啟動**

受條件（2）的限制，要求使用者調用 CActiveScheduler::Add() 之前必鬚髮起非同步
調用:

// 構造調度器對象
myAO->IssueAsyncRequest(); // 發起非同步請求
CActiveScheduler::Add(myAO); // 自動啟動調度器，等待非同步作業完成

顯然，這不能解決"需求-2"。不能在初始化的時候啟動多個使用中的物件。只能在第一
個使用中的物件的 RunL 裡面啟動其它使用中的物件。

另外，調度器啟動之後，調用棧中包括了調用 Add 的這個函數（當前函數）。如果
在 Main 函數之類的地方調用 Add，自然沒有問題。但是如果在使用中的物件的構造函
數（或者其它成員函數）調用 Add，就會造成使用中的物件和調度器的強烈耦合 ――
使用中的物件必須保證自己在調度器啟動並執行期間一直存在。

這個方法不符合要求。

**第二個方法：發起第一個非同步請求的時候啟動**

CActiveScheduler::Add(myAO1);
CActiveScheduler::Add(myAO2);

myAO1->IssueAsyncRequest(); // 自動啟動

首先這也不能解決"需求-2"。其次也存在耦合問題：怎麼在發起非同步請求的時候啟
動調度器。我能想到的方法是在調用 SetActive 的時候啟動，但是這個實現似乎會
帶來無盡的惡果。

**總結**

調度器的啟動不能依賴於某個使用中的物件的狀態，應該由程式獨立控制。如果啟動的
時候不能滿足條件，這是應用程式的嚴重BUG，需要強製程序員解決，所以 Panic
也是很合理的。所有這些原因都綜合起來，很自然就是現在這樣的一種啟動方式。

應該還有很多種不同的設計，其中有些可以滿足所有的需求，但是使用和實現的複
雜程度恐怕會大於現有的架構。可以把不爽的地方都列出來，說不定哪天能攢出來
一個比現有結構更好的呢