技术奇异点

前两天把 WordPress 的 WP-touch 插件配好了（ sipoint.wordpress.com 本来就支持这个插件，这次配置的是 techsingular.net ）。这样有 iPhone/iPod touch 的朋友阅读就方便多了。

如今几乎所有用过笔记本电脑的人都能说出镜面屏的缺点和优点。缺点是反光，如果你的座位正后面有一盏灯，那么使用镜面屏是很痛苦的。优点是色彩艳丽。在顺理成章的接受这个优点的时候，很少有人想到色彩艳丽的根源。前些天看到有人在网上问这个问题，我突然想到原来镜面屏的优点就来自它的缺点。

非镜面屏能很好地应对使用者后方的光源，原因在于把光源发出的光通过漫反射平均的分散到各个方向。反过来说，如果你的侧后方有一个光源，那么非镜面屏就会把这个光源的一部分光反射到你的眼中，不管你如何调整角度，只要这个光源还在你的后方，反射到你眼中的光量都不会变化。这就是漫反射的特点。而镜面反射遵循入射角等于反射角的反射定律，所以镜面屏会把正后方光源的光线几乎 100% 的反射到使用者眼中。但是只要稍稍调整角度，让光源处于侧后方，光源的光线就几乎不会通过屏幕进入使用者眼中。所以镜面屏是通过牺牲对正后方环境的容忍度，降低了整个环境对显示效果的干扰。而非镜面屏以牺牲抗环境干扰的整体能力换取对正后方环境的容忍。

When in doubt, use brute force.
—— Ken Thompson

Keep it simple, stupid!

在『天涯』上看到一个帖子提到米格-25。这个前苏联空军中神秘的家伙当年经常在北约的雷达上以三倍音速一闪而过。在以色列曾经遭遇 F-4 并且被后者占据尾追位置发射了空对空导弹，结果是 F-4 看到米格- 25 在导弹发射之后突然加速离开。以当时北约国家 —— 主要是美国 —— 对航空技术的理解，要达到米格- 25 展示出的能力，苏联非掌握钛合金加工工艺不可 —— 在三马赫速度下产生的高温中，除了钛以外，任何低密度金属都会变成橡皮泥，可是即使是今天人类对钛金属的加工能力仍然很有限，完全无法令其成型为航空器零件。还有，为了完成被赋予的防卫广阔的西伯利亚的任务，西方认为米格- 25 必然拥有精巧的机载电子设备。

当 1976 年一个叛逃的苏联飞行员给西方送来一架米格- 25 的时候，后者迫不及待的要看看心目中尖端的机身工艺和电子技术。结果，发现这个三倍音速飞行的家伙竟然是个大钢锭 —— 几乎完全用不锈钢这种在西方看来连普通飞机都造不了的重金属。整架飞机用可称为『狂暴』的发动机才体现出邪恶的航空特性。那个能蹲下一个成年人的喷口最能说明其狂野，不光巨大，而且固定在最大状态，完全没有任何调节机构 —— 在维持三马赫速度而产生的高温下，任何多余的机构都是巨大的不稳定因素。困扰了西方十几年的关于如何实现三倍音速的机身加工就这样被苏联用暴力一举攻克。

还有西方幻想中先进的机载电子设备，不过是把大量的电子管塞到硕大的机头中。如果在地面打开机头的电子管雷达，能把前方 100 米内的生物烤熟。

北极熊独一无二的风格把技术和暴力美学联系到一起。这是人类在技术有限的前提下追求极至的精神。如果有一天人类认识宇宙的能力走到尽头，还能够依靠这种精神在探索的路上走很远。刘慈欣的《三体II · 黑暗森林》和弗诺 · 文奇的《天渊》幻想的就是这种无奈但又令人神往的境地。只是半个世纪之前那个神秘的红色帝国已经在这个境界肆意驰骋了。

最近一件有意思的事情是 Oracle 质问询问 Open Solaris 社区从一个 Open Solaris 这样的 open source 项目如何盈利。老实说比起 IBM 这种虚伪的家伙，我更喜欢 Oracle 的直率 —— 本来么，这个问题几乎人人心中都有。那么，为什么有的 open source 项目 —— 比如 Linux kernel、WebKit、GCC 可以蒸蒸日上；而另一些，比如 MySQL、Open Solaris 则奄奄一息呢？

其实答案还是在于那句老话，open source 是程序员写给自己的工具，它的生存不取决于盈利，不沿循普通的商品交换的资金流动途径，而在于直接提高其创造者社区的生产力。一个 open source 项目能否生存，在于其用户群能否成为自身的维护者和改进者。所以，第一等天然的 open source 项目是程序开发工具。第二等天然的 open source 项目是各种各样的库。同样的功能，提供 GUI 和提供 API 对于一个开源项目来说是生死攸关的差异。使用 GUI 的人极难成为一个产品的维护者。使用 API 的人不是在真正的『使用』产品，而是在创造自己的产品，同时他们有能力也乐于成为他们所依靠的 open source 项目的维护者和改进者。所以作为开源软件 WebKit 之类的库能够得到比 FireFox 之类的成品浏览器更好的发展。事实上，要求 FireFox 把自身的结构整洁化以便能够剥离出其『核心』功能供其它类型的产品使用一直是业界对 FireFox 的一个要求。

一个 open source 项目提供的能够将被其他开发者自由的集成到其它产品中的紧密度是它能否生存的关键。在这一点上，GPL 许可证的项目都游走在生死线上，因为它们很难把自己作为一个非 GPL 产品的不可分隔的一部分。只有 Linux kernel 可以算一个例外，因为 kernel 的特殊边界保证了它可以集成到其它非 GPL 产品中。而 LGPL 和 BSD 的项目就可以生活的好一些。诸如 MySQL 之类的产品，GPL 版只能作为独立的服务集成到商业产品里，自然不如 SQLite 这样能够被无缝集成的项目发展得好。

有段在 Windows XP 和 Vista 上工作了四五年都没有问题的代码在 Windows 7 上出了问题。还好问题定位并不困难：一个 COM 接口的方法返回错误值 ——『调用了为另一个线程 marshall 的接口』。获取这个接口的线程用了『Apartment Threaded』模式。这个模式不允许多个线程直接共享一个 COM 接口的指针，线程间传递 COM 接口必须在一个线程中用 CoMarshalInterThreadInterfaceInStream() 把要传递的 COM 指针转换成 IStream 的形式，再在另一个线程里用 CoGetInterfaceAndReleaseStream() 转换回来。在 Apartment Thread 模式中得到的 COM 指针不是直接指向 COM 组件的裸指针，而是一个 proxy 的指针。一个 proxy 对象只能在一个线程中使用，上面的那对 API 就是用 IStream 作为中间载体在不同线程间创建新的 proxy 对象。正是因为这个 proxy 对象的存在，Apartment Thread 模式能够把多线程对一个 COM 组件的并行调用序列化（Serializing），这样才能让没有考虑多线程的 COM 组件能在多线程环境中被使用。出问题的那段代码就是没有遵循这个约定直接传递了在一个线程里创建的 proxy（最初的开发者可能根本不知道 Apartment Thread 里 proxy 的存在，把这个 proxy 当成了可以直接指向 COM 的指针）。

从 COM 出现的时间来说，Apartment Thread 也算是一种承前启后的设计。让设计时没有考虑线程安全的 COM 组件能够不加修改的在多线程环境中使用。尽管现在看来当时（现在似乎也并无改进） Microsoft 介绍 Apartment Thread 的 文档实在够烂，98 年我怎么也读不懂，三年以后 Sun 的 EJB 文档才让我理解了这种设计。

为了能并发访问线程不安全的 COM 组件，引入一个做为中间层的 proxy 是必要的。但是 Microsoft 的设计者欠考虑的是完全没有必要为每个线程引入一个 proxy。即使每个线程必须有一个 proxy，那么也应该用另一个中间层来隐藏这些 proxy，让第三方开发者只看到一个 proxy。在必须引入中间层的一个地方，最多只应该有一个外部可见的中间层。

COM 在这个问题上的历史疏忽不应该留到现在，今天 Microsoft 完全可以用一种不破坏向后兼容的方式来解决这个问题：放松 Apartment Thread 模式下对 proxy 的约束，通过重新实现 proxy 让同一个 proxy 对象可以在多个线程里直接传递和使用。同时把 CoMarshalInterThreadInterfaceInStream() 和 CoGetInterfaceAndReleaseStream() 变成类似 no-op 的操作。这样，无论是不明就里直接传递了指针的代码还是规规矩矩 marshall proxy 的代码都能正常工作。遗憾的是，Windows 7 不但没有让这样的变化名正言顺，反而把 Vista 和之前版本里本来在实现上放松的约定收紧了。这样的做法从严格的文档意义上说不算错误，但是在对待开发者的态度上，是一种缺乏细心的考虑，是 API 的退化。

最近公司的软件的新版本做得差不多了。给第三方开发者介绍如何开发扩展的例子还没更新。这次 API 上没什么重大变化。所以工作量应该不大。

我找到例子的工程文件，双击。Visual Studio 2008 被启动，然后报告：您打开了一个旧版本的 Visual Studio 创建的工程，是否要转换为新版本的格式？—— 因为上一次公司软件发布的时候市面上最新的 Visual Studio 还是 2005。看来 Visual Studio 2008 对工程文件格式做了大调整。这样的格式转换我很不喜欢，因为前后的文件差异很大，diff 两者很难看到什么地方变化了。只好转换之后再看如何 clean-up 尽量让版本之间的变化比较清晰吧。

转换界面是 Wizard 形式的，如果不直接点 Finish 的话，要点击两次 Next 按钮才会结束。第一步询问是否要备份原始文件再转换，最后一步询问是否要输出转换 log。因为有 Version Control 系统，我既没选备份也没选输出 log，一路 Next 下去。Visual Studio 工作片刻，硬盘响了一会儿。转换完成。我用 Version Control 系统的 diff 查看了一下，变动了一行 —— 文件里 Visual Studio 的版本号从 8 变成了 9。

以及，DirectDraw 是这个星球上最屎的 API。

消息驱动应用的出现把软件开发的复杂度提升了一个数量级。消息驱动应用的开发者要处理来自用户、操作系统、其它应用、其它库和扩展、以及自己编写的代码产生的几百种事件。每种事件的个数和发生的顺序都几乎无法预测。预测无穷的组合需要逻辑，而开发过软件的人知道我们从来不用逻辑。

第一消息循环

学过 Win32，Cocoa，或者 QT 开发的人一定知道主消息循环（main event loop）这个概念。（如果你只会用 Java，那么可以学习一下这些东西再来往下看；或者马上放弃这篇文章，并且默念『线程、线程 ⋯⋯』。）主消息循环是一段类似下面的代码（Cocoa 的例子）：

只熟悉 Win32 的人只要把 nextEventMatchingMask 当成 GetMessage() ，把 sendEvent 当成 SendMessage() 也可以大致看懂。nextEventMatchingMask 从消息队列里取出形形色色的消息 [1]，以 sendEvent 为 call stack 发端调用到开发者编写的不同代码。在一个消息驱动程序里的大部分代码的 call stack 都会包含 sendEvent 或者 SendMessage，没有运用多线程的应用（也就是代码都在主线程里运行 [2]）这个比例会达到几乎 100% [3]。

大多数时候，除了在 debugger 的 call stack 里，是看不到这个消息循环的。它已经被封装到诸如 NSApplicationMain() （Cocoa）或者 CApplication::Run() （MFC）这样的函数中。为了和下面的描述对应，我们把这个不常见面的东西称为『第一消息循环』。

第二消息循环

讨论第二消息循环最好先明白它要解决什么问题。第二消息循环要解决的并非单一问题。其中比较重要的一个源自 Windows 3.x 时代。那时候 GUI 环境还是单线程，而且整个 Win16 系统只有一个单独的线程。所以，如果某一个程序处理按钮按下的代码一口气运行了五分钟，那么整个系统也会僵死五分钟。比如下面这个事件处理的片断：

所以，那时候非常『先进』的技术就是在运行时间很长的代码里不时调用 GetMessage() 和 SendMessage() 这对 API。这样就可以给其它的事件处理代码一个运行的机会。比如上面那段代码就会改成下面这样：

运行后会出现这样的 call stack（这个例子里另一个窗口的鼠标拖拽操作的消息得以有机会被处理）：

第二消息循环未必是个字面意义上循环，因为 get event 和 send event 并不一定要放到循环里。但是一般来说都是这么做的，所以这个名称就沿用下来。『第二』不是指代码中出现的第二个消息循环，而是指在运行时出现在第一消息循环里的第二层循环（见下文的『第三消息循环』）。

陷阱！

所以，现在你的程序可以在按钮按下但是无法弹起（因为 onClick 不会很快返回）的这段时间里处理其它的事物了。听起来不错！但是也可能是个通向灾难的陷阱。你必须保证开启第二循环的函数在 sendEvent 调用的前后不会访问任何其它消息处理函数可能修改的数据结构。

马上你会意识到，如果对第二消息循环不加限制（就是像第一循环那么简单），那么在 send event 前后保护数据完整性是个不可能完成的任务。消息驱动的程序开发最重要的假设就是事件处理函数可以在某种程度上被认为是近乎原子的操作 [4]。而第二消息循环粗暴的打破了这个假设。如果第二消息循环和第一循环一样，那么任何事件处理函数都可能是被第一或第二循环调起，包括打开第二消息循环的函数，幸运的话你会拥会有第三消息循环！

所以第二消息循环的处理必须有严格限制。实际上，在 Win16 时代，用来防止整个系统锁死的第二消息循环是不会 get 和 send 任何属于同一个应用的事件的（也就是不能像例子中那样用 NSEventAnyMask）。如果为了防止用户产生程序僵死的印象，第二消息循环也会用来显示一个进度条，或者一个不断回旋的图标，以及重绘某些重要的窗口。但是对同一应用的消息处理也通常仅限于此。模态对话框也是通过第二消息循环完成，这个循环不会处理任何事件，除了对话框本身的事件和重绘其它窗口。所以，模态对话框的代码通常只会修改那些在打开对话框的时候新创建的数据结构，不会修改和访问程序的其它部分；而且任何窗口的重绘处理都要避免修改任何数据 [5]。

接下来，在后 Win16 时代，第二消息循环最主要的作用是处理鼠标拖拽（drag, drag and drop）。处理鼠标拖拽的第二消息循环只能处理鼠标的 move 和 drag 事件，并且遇到 mouse release 要立刻退出循环 [6]。即便如此，鼠标拖拽仍然是最容易导致应用崩溃的 use case。

今天我们有强占式多任务操作系统，有多线程，完全可以避免仅仅为了防止 UI 僵死而使用第二消息循环。在这方面有许多更好的替代方案。一种做法是把耗时的任务放到主线程之外的其它线程。线程提供了更完备的同步保护操作。在使用第二消息循环的情况下模拟线程的同步保护不是不可能，比如，在 sendEvent 的前面设置一个 flag，后面清空这个 flag，然后在其它事件处理函数里加上这种代码：

但是这样做会让同步保护的操作和要保护的数据在代码中分离。你会越来越无法看清你真正要保护的是什么。最终你只能假定第二消息循环会破坏『一切』数据，让后在『一切』事件处理函数中加上这样的保护。

另一种方法是把很耗时的操作切分成多段，把每段放到一个 timer 里运行 [7]。Timer 的好处在于每个消息处理函数和 timer 函数都是原子操作（除去有其它线程干扰的情形）。缺点在于在每次 timer 运行之间要保持中间数据，并且正确处理有可能被其它事件处理函数修改的数据结构，不过以函数为边界来保证数据结构处于完整的状态的做法带来的复杂度仍然相对低廉。

所以，你没有控制全局！

不加控制的第二消息循环是灾难。有人会傻到使用它吗？用用 Windows 的 DirectDraw 你就知道了。DirectDraw 的很多 API 函数都会在内部开启第二消息循环。使用 DirectDraw 的开发者根本无法对这个循环做任何控制。所以用 DirectDraw 根本没法编写一个安全的应用程序。

举个例子，如果你的程序里对于某个控件的鼠标单击和双击分别对一个 DirectDraw 的内容进行不同的操作，恭喜你！首先，在 DriectDraw 之外，Windows 会为你做一件事情：在用户一次双击鼠标的时候会分别触发一个单击消息和一个双击消息。此时你的单击消息处理函数会首先被调用，如果里面调用了 DirectDraw 的 API，那么很有可能这个 API 会开启第二消息循环，后者会调用你的双击消息处理函数。你应该用什么样的 mental model 来设计这两个函数？最简单的方案就是用 crash 来教育用户！

所以，别把 DirectDraw 嵌入到你的文件浏览器类型的应用程序或者 email client 里。在这种有复杂 UI 交互的应用里使用 DirectDraw 是自寻死路。DirectDraw 是给全屏程序和一次播放一个电影的播放器用的（即使有问题，用户体验的是电影而不是你的 UI，他们没空动鼠标，只会在上厕所之前按空格）。

结论

今天，只有模态对话框和鼠标拖拽还需要使用第二消息循环。长时间的操作应该使用 timer 和多线程避免 UI 锁死。为了降低复杂度，即使使用 timer 和多线程避免 UI 锁死，也应该尽可能在此期间限制用户操作（比如用模态对话框显示进度条，禁止『取消当前操作』之外的一切 UI 操作。如果不喜欢模态对话框，可以在主窗口显示操作状态并在用户发出其它 UI 操作的时候自动取消后台任务（大多数文件浏览器都在后台遍历当前文件夹，用户转向其它文件夹的时候自动取消操作）。如果后台任务和用户的 UI 操作必须同时进行，那么，祝你好运。

脚注

1. 消息队列的消息产生于何处对开发者来说并不可见。一般只要理解成用户的各种操作会自然的产生队列中的各种事件就好。良好的设计原则是对消息在队列中是否重复以及顺序如何尽量不做假设。
2. 这里说的应用代码不包括 Cocoa 这样的 framework，Cocoa 和 QT 自己都会创建一些线程。
3. 同理不包括 framework 本身。
4. 这是因为大多数事件驱动的 framework 都把事件处理放到单一的主线程，即使有多个窗口也是如此。曾经有一个特例 —— BeOS，每个窗口拥有自己的独立线程。BeOS 的开发复杂度也是它消失的原因之一。Win32 可以有多个线程拥有独立的消息队列和消息循环。不过实际中很少用到。
5. Mac OS X 里面早就提供 buffered window，Windows 终于从 Vista 开始提供，从此窗口的重绘不再单单依靠开发者编写的重绘代码（在内容没有变化的时候）。所以重绘消息现在通常被排除在第二消息循环需要处理的消息之外。
6. 事实上，处理鼠标拖拽的循环的目的就在于过滤信息，而并非改变应用的响应行为和代码运行顺序。但是这种做法沿袭了 Win16 时代为了提高响应敏捷度的方法的副作用。
7. Timer 这种方法用 Win16 的系统就足以实现。但是 timer 要求用户编写的第一消息循环在程序比较空闲的时候能够调用 timer 处理函数。在 Win16 时代，第一消息循环主要还是手工编写，所以 timer 这种方式和手工编写第二消息循环相比并不省事。今天第一消息循环都被封装在各种 framework 里，而且基本都内建对 timer 的支持。

闲谈的时候，如果有人的主意让我想到读过的科幻小说中的事物，我一定会指出来。并不是因为我想表达『早就有人想到了』，而是想让人分享一下如果这些主意真的实现了会让我们的生活发生什么变化。

前不久有个朋友从西藏回来。他说在没有人类改造自然的痕迹存在的地方，会感到自己每天在城市里做的事情多么没有意义。我能理解这种感觉是真实而且值得体验的。但是，我也怀疑，如果我们没有创造并且体验今天的这种文明，我们是否还会有这种对纯粹的不加改造的自然的感觉；如果始终生活在那种环境中，我们是否会放弃好奇心最终达到今天的文明。

其实我们今天的生活和几个世纪之后比起来，又何尝不是今天的西藏和国际化大城市的差别？科幻小说并不是预测未来的晴雨计，但是明白没有水晶球的我们应该知道这是我们能够得到的最好的东西，那是我们某种可能的未来。回顾是一种特殊的感受。而科幻是让我们除了亲身经历自己的世界之外，还能回顾它的一种方式。