一. 人生三大問：我是誰，我從哪來，我到哪去？
1.1. 協程是什么
我們知道，在現代計算機的世界里，有進程，有線程，有了他們兩個，我們就足以應對大多數的并發應用，更不用提在網絡編程的世界里還有select和epoll這種手段來應對并發。
那么協程又是什么什么呢，在go語言里，這玩意叫做goroutine，在python里被稱為green thread 或者其他的什么玩意，其與操作系統的線程的最大區別就是它是用戶態的，即不需要內核去調度CPU，一切在用戶態解決。
其工作流程一般可以認為是：
（1） 任務1執行到阻塞位置，通過yield讓出CPU
（2） 調度任務使用resume恢復任務2的上下文，從任務2上次yield的位置執行任務2
（3）以此類推……
看起來是不是很像線程和進程？保存當前上下文，恢復目標上下文，讓出CPU…這套令人窒息的操作。
所以它被稱為協程（或者纖程），很像線程，是一個調度單元，但一般很輕量，在用戶態。
1.2. 協程能解決什么問題？我們為什么需要協程？
協程是輕量級的線程，但是它相對于線程有什么優勢呢？
（1） 不需要陷入內核調度，因此調度效率要比線程/進程高。
（2） 因為是在同一個線程運行，因此臟讀、鎖這種問題都tan90°了。
這就很適合拿來在一些場景替代線程，或者與線程配合作為N:M的實現，進一步壓榨系統的并發能力。
當然對于一些前端的朋友，協程可以將異步調用封裝成（看起來的）同步調用，防止陷入回調地獄的尷尬境地中。
比如說傳統的ajax操作一般都是：
ajax.get(url, (request)=>{
show(request, ()=>{
//do something after showed
})
})
你可以hack進ajax的get：
function get(url) {
//send packet and register callback
callback=callback;
yield;
}
function callback() {
resume get;
}
然后用戶態就可以寫成：
ajax.get(url);
show();
somethingAfterShow();
看起來就跟同步的是一樣一樣的。當然前端是不能用我下面說的ucontext組件的，這里只是舉個回調地獄的例子，C/C++也有類似的場景，只不過前端出現的更廣；好在他們已經有了Promise和ES6的async語義可以解決回調地獄的問題了。
1.3. 如何實現協程？
要說到如何實現，我們就需要先知道我們具體需要實現哪些東西：
（1） 協程的數據結構，用于保存上下文
（2） 調度器，用于調度協程
（3） resume語義，運行某個特定的協程（從他上次讓出心愛的時間片處開始）
（4） yield語義，協程主動讓出CPU。
從經典C學出來的小朋友們（比如我）可能就很難理解yield語義的作用，因為之前都沒有接觸過yield這個東西。
簡單來說，yield就是讓出CPU控制權。在多線程中，線程的調度是由內核完成的，碼農作為用戶基本上無從插手。而當你在用戶態實現協程時，理所當然時間片是否讓出，如何讓出都要在用戶態完成，那么讓出的這個動作，就是yield——當然，為了保證下次運行當前任務還能從你讓出的這個時空開始，你當然需要把這個任務的上下文保存到某處……比如……一個ucontext結構中？
二. 從ucontext說起
2.1 ucontext_t 以及上下文
linux肥腸貼心的實現了ucontext結構，給用戶讓渡了一部分控制代碼上下文的能力，可喜可賀，可喜可賀。
ucontext_t 中保存的上下文主要包括以下幾個部分：
（1） 運行時各個寄存器的值
（2） 運行棧（堆就不用保存了，你存不存，他都在那里，不來不去）
（3） 信號
基本上有了這些，就可以有效地在用戶態保存犯罪現場了。當然以上的枚舉只是一個大概的思路，具體落地還是有些細微的差別的。
那么ucontext_t的定義如下：
typedef struct ucontext {
/* pointer to the context that will be resume when this context returns */
struct ucontext *uc_link;
/* the set of signals that are blocked when this context is active */
sigset_t uc_sigmask;
/* the stack used by this context */
stack_t uc_stack;
/* a machine-specific representation of the saved context */
mcontext_t uc_mcontext;
...
} ucontext_t;
當然，系統實現的具體內容可能遠遠不止這些，但是標準里的規定，就是至少有這些字段。
OK，那我們就此得到了一個可以保存上下文的結構，它有
（1） 當本上下文退出時，將會激活的上下文
（2） 當本上下文激活時，需要被阻塞的信號
（3） 可以指定的運行棧，上下文可以在這個棧上運行
（4） 硬件相關的上下文集，保存具體的寄存器
我們可以發揮一下想象力，有了他們我可以做什么呢？
（1） 指定某個函數運行，然后運行完了恢復到調度器的上下文繼續調度，用uc_link字段實現——是不是頗有點線程池的感覺？
（2） 指定上下文運行在某個指定的棧上
（3） 把上下文切來切去，就像setjmp和longjmp干的事情一樣
為了實現這些功能，linux提供了一組api：
int getcontext(ucontext_t *);
int setcontext(const ucontext_t *);
void makecontext(ucontext_t *, (void *)(), int, ...);
int swapcontext(ucontext_t *, const ucontext_t *);
有了它們，我們就可以手動管理上下文。下面來介紹一下這些api。
這些api的具體實現，可以參考這篇文章。
其實就是使用匯編保存和恢復了包括rbx，rbp，r12，r13，r14，r15，rdi，rsi，rdx，rcx，r8，r9等寄存器。
2.2 getcontext 和 setcontext
getcontext和setcontext的原型如下所示：
#include <ucontext.h>
int getcontext(ucontext_t *ucp);
int setcontext(const ucontext_t *ucp);
顧名思義，getcontext就是獲取當前上下文，并保存到ucp指向的ucontext_t實例中。setcontext則是從ucp指向的實例恢復上下文到現場。
不過setcontext還是有幾點需要注意：
- 如果
ucp的來源是getcontext，則是像上次getcontext調用剛返回一樣運行。 - 如果
ucp的來源是makecontext，則會先調用makecontext的func函數（就是第二個參數那個函數指針），func返回后進入uc_link指定的上下文中執行。如果這個成員為NULL，則線程退出。 - 還有一種來源是signal handler，就是
sigsetjmp和siglongjmp，但是現在已經很少用了。
2.3 makecontext 和 swapcontext
#include <ucontext.h>
void makecontext(ucontext_t *ucp, void (*func)(), int argc, ...);
int swapcontext(ucontext_t *oucp, const ucontext_t *ucp);
makecontext調用可以修改（modify）getcontext得到的上下文——也就是說make之前，你要先get。
makecontext可以做下面幾件事：
- 指定運行棧
- 指定swap或者set調用后運行的函數（指定為func）
- 指定上面那個函數運行完后，要切換到的那個上下文
swapcontext做的事情就很簡單：
getcontext到oucp，然后用ucp去setcontext。
三. 協程的create, resume, yield
3.1 創建
要運行協程，首先要創建協程（廢話，pia！）
而要自己擼一個協程庫，則需要創建一個Scheduler來調度他，并且在他上面去創建協程。
由于協程剛剛創建時，是不需要運行的，直到第一次切到這個協程，所以創建的時候我們只需要準備好運行的函數指針，和一些其他標志狀態和必要的量就可以了。
聽起來很簡單，是不？
3.2 resume
協程的喚醒，就需要準備一些事情了。
首先，我們可能需要在喚醒之前把現場保存下來。然后喚醒目標協程的上下文……當然這就需要我們先判斷一下協程是否是第一次喚醒，第一次的話，就需要get & make一下context，不是的話，直接setcontext就可以切到目標協程了。寫成偽代碼大概是這樣：
if target coroutine is new:
getcontext =>target coroutine
target stack => target coroutine
makecontext => target coroutine
getcontext => schedule routine
set context <= target routine
else:
target stack => target corutine
swap coroutine schdule context <=> target context
3.3 yield
協程的讓出，和喚醒干的事差不多，只不過變成了它的逆過程：保存棧，恢復上下文到調度器的上下文。
寫成偽代碼大概是這樣嬸的：
save stack
tag this routine old routine
swap context target context <=> schdule context
這樣執行完yield之后，就可以切到resume剛執行完swapcontext那樣了。是的，就像你剛剛執行完那個調用，然后什么都沒發生一樣。
四. 云風大大的coroutine庫——200行代碼帶你實現協程
4.1 基于ucontext的實現思路：保存棧，恢復棧
云風大概6年前（啊我和大佬們的差距究竟有幾個十年）寫了一個coroutine的C語言實現，非常簡潔，值得我們這些菜雞學習。我把它移植到了C++語言版本，調用和依賴關系能稍微清楚一些，也沒有那些滿天飛的指針，對新手還算友好。不過我們還是講云風的版本吧。
其大概是實現了兩套接口：
struct schedule {
char stack[STACK_SIZE];
ucontext_t main;
int nco;
int cap;
int running;
struct coroutine **co;
};
struct coroutine {
coroutine_func func;
void *ud;
ucontext_t ctx;
struct schedule * sch;
ptrdiff_t cap;
ptrdiff_t size;
int status;
char *stack;
};
struct schedule 實現調度功能，struct coroutine則保存協程使用的目標函數、上下文和棧。
4.2 resume的實現
void
coroutine_resume(struct schedule * S, int id) {
assert(S->running == -1);
assert(id >=0 && id < S->cap);
struct coroutine *C = S->co[id];
if (C == NULL)
return;
int status = C->status;
switch(status) {
case COROUTINE_READY:
getcontext(&C->ctx);
C->ctx.uc_stack.ss_sp = S->stack;
C->ctx.uc_stack.ss_size = STACK_SIZE;
C->ctx.uc_link = &S->main;
S->running = id;
C->status = COROUTINE_RUNNING;
uintptr_t ptr = (uintptr_t)S;
makecontext(&C->ctx, (void (*)(void)) mainfunc, 2, (uint32_t)ptr, (uint32_t)(ptr>>32));
swapcontext(&S->main, &C->ctx);
break;
case COROUTINE_SUSPEND:
memcpy(S->stack + STACK_SIZE - C->size, C->stack, C->size);
S->running = id;
C->status = COROUTINE_RUNNING;
swapcontext(&S->main, &C->ctx);
break;
default:
assert(0);
}
}
可以看出，過程和我在3.2節中所講的基本一致，這里他使用了四個宏去定義協程的狀態，如果是剛初始化的COROUTINE_READY狀態，則get->make->swap三連擊。如果是運行到一半被切出來的COROUTINE_SUSPEND協程，則恢復棧空間后，swap到當時的上下文。
這里使用S->main函數去保存調度器的上下文。
makecontext前指定了S->stack作為運行棧，可以看到，后面的操作，都是在這個棧空間上進行的，是不是很有趣？在堆上分配了空間，作為一個運行棧。
需要注意的是，這里的makecontext調用，使用的是一個mainfunc函數，而非直接采用C->func，讓我們看看mainfunc里面做了什么：
static void
mainfunc(uint32_t low32, uint32_t hi32) {
uintptr_t ptr = (uintptr_t)low32 | ((uintptr_t)hi32 << 32);
struct schedule *S = (struct schedule *)ptr;
int id = S->running;
struct coroutine *C = S->co[id];
C->func(S,C->ud);
_co_delete(C);
S->co[id] = NULL;
--S->nco;
S->running = -1;
}
是的……他調用了C->func，然后在func返回后將這個協程從S的協程隊列里抹掉了。可以，這很線程池。
4.3 yield的實現
yield的實現則更為簡單：
void
coroutine_yield(struct schedule * S) {
int id = S->running;
assert(id >= 0);
struct coroutine * C = S->co[id];
assert((char *)&C > S->stack);
_save_stack(C,S->stack + STACK_SIZE);
C->status = COROUTINE_SUSPEND;
S->running = -1;
swapcontext(&C->ctx , &S->main);
}
獲取運行協程、保存棧、修改狀態、切換上下文，一氣呵成。
比較有意思的是_save_stack的實現：
static void
_save_stack(struct coroutine *C, char *top) {
char dummy = 0;
assert(top - &dummy <= STACK_SIZE);
if (C->cap < top - &dummy) {
free(C->stack);
C->cap = top-&dummy;
C->stack = malloc(C->cap);
}
C->size = top - &dummy;
memcpy(C->stack, &dummy, C->size);
}
沒有使用一行匯編代碼，用一個局部變量dummy得到棧頂地址，然后與top作差，保存棧空間，還是蠻有意思的，需要注意的就是棧的增長方向。
至此，云風的協程實現基本上就可以濾清楚了，至于如何初始化，如何使用，那就去看他的源碼吧~
五. 來自Tencent的libco：讓我們hook進socket吧！
To be continued.
