微線程領(lǐng)域（至少在 Python 中）一直都是 Stackless Python 才能涉及的特殊增強(qiáng)部分。關(guān)于 Stackless 的話題以及最近它經(jīng)歷的變化，可能本身就值得開辟一個專欄了。但其中簡單的道理就是，在“新的 Stackless”下，延續(xù)（continuation）顯然是不合時宜的，但微線程還是這個項目 存在的理由。這一點(diǎn)很復(fù)雜……

剛開始，我們還是先來回顧一些內(nèi)容。那么，什么是微線程呢？ 微線程基本上可以說是只需要很少的內(nèi)部資源就可以運(yùn)行的進(jìn)程 ― 并且是在 Python 解釋器的單個實例中（在公共內(nèi)存空間中，等等）運(yùn)行的進(jìn)程。有了微線程，我們就可能在目前中等性能的 PC 機(jī)上運(yùn)行數(shù)以萬計的并行進(jìn)程，還可以每秒鐘幾十萬次地在上下文之間切換。對 fork() 的調(diào)用或標(biāo)準(zhǔn)的 OS 線程調(diào)用根本不能達(dá)到這個程度！甚至所謂的“輕量級”線程庫中的線程也比這里提出的微線程“重”好幾個數(shù)量級。

我在本專欄中介紹的輕便線程的含義與 OS 線程的含義有一點(diǎn)不同。就這點(diǎn)而言，它們與 Stackless 所提供的也不盡相同。在很多方面，輕便線程比大多數(shù)變體都簡單得多；大多數(shù)關(guān)于信號、鎖定及諸如此類的問題都不存在了。簡單性的代價就是，我提出了一種“協(xié)作多線程”的形式；我覺得在標(biāo)準(zhǔn) Python 框架中加入搶占并不可行（至少在非 Stackless 的 Python 2.2 中 — 沒有人知道 __future__ 會帶來什么）。

輕便線程在某種意義上會令人回想起較早的 Windows 和 MacOS 版本的協(xié)作多任務(wù)（不過是在單個應(yīng)用程序中）。然而，在另一種意義上，輕便線程只不過是在程序中表達(dá)流的另一種方式；輕便線程所做的一切（至少在原則上）都可以用“真正龐大的 if/elif 塊”技術(shù)來完成（蠻干的程序員的黔驢之計）。

一種用簡單的生成器模擬協(xié)同程序的機(jī)制。這個機(jī)制的核心部分非常簡單。 scheduler() 函數(shù)中包裝了一組生成器對象，這個函數(shù)控制將控制流委托給合適的分支的過程。這些協(xié)同程序并不是 真正的協(xié)同程序，因為它們只控制到 scheduler() 函數(shù)和來自該函數(shù)的分支。不過出于實用的目的，您可以用非常少的額外代碼來完成同樣的事情。 scheduler() 就是類似于下面這樣的代碼：
清單 1. 模擬協(xié)同程序的 Scheduler()

def scheduler(gendct, start): global cargo coroutine = start while 1:  (coroutine, cargo) = gendct[coroutine].next()

關(guān)于這個包裝器要注意的一點(diǎn)是，每個生成器／協(xié)同程序都會生成一個包含它的預(yù)期分支目標(biāo)的元組。生成器／協(xié)同程序基本上都在 GOTO 目標(biāo)處退出。為了方便起見，我還讓生成器生成了一個標(biāo)準(zhǔn)的 cargo 容器，作為形式化在協(xié)同程序之間傳送的數(shù)據(jù)的方法 — 不過您也可以只用已經(jīng)達(dá)成一致的全局變量或回調(diào) setter/getter 函數(shù)來傳送數(shù)據(jù)。Raymond Hettinger 撰寫了一個 Python 增強(qiáng)倡議（Python Enhancement Proposal，PEP），旨在使傳送的數(shù)據(jù)能被更好地封裝；可能今后的 Python 將包括這個倡議。