关于 活动对象调动器的 介绍

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
也是很合理的。所有这些原因都综合起来，很自然就是现在这样的一种启动方式。

应该还有很多种不同的设计，其中有些可以满足所有的需求，但是使用和实现的复
杂程度恐怕会大于现有的框架。可以把不爽的地方都列出来，说不定哪天能攒出来
一个比现有结构更好的呢 :-P