“協(xié)程”（coroutine），就是把linux epoll的異步IO機制通過長跳轉（long jmp）封裝起來，形成一個在用戶看來“連續(xù)的”流程。
所有操作系統(tǒng)的異步IO，都分為啟動函數(shù)和回調函數(shù)。
以Linux為例，啟動函數(shù)負責往epoll框架里添加讀寫事件。
在事件觸發(fā)之后，再通過回調函數(shù)去進行下半部的處理。
整個事件處理過程，與Linux內(nèi)核里的中斷處理差不多。
一個完整的IO流程需要回調好幾次，而且讀代碼時到處查找回調函數(shù)在哪里設置的。
甚至，有的程序員會中途修改回調函數(shù)的指針[捂臉]
C的函數(shù)指針比C++的虛函數(shù)更“靈活”的地方是，C++的虛函數(shù)表在編譯時就固定了，但C的函數(shù)指針可以在運行時修改（它就是個普通變量）。
然后，就真有人半截里修改它，讓代碼的可讀性急劇下降。
再然后，就出現(xiàn)了coroutine，看上去至少是同步的了。
程序流程在一個函數(shù)里跳轉，就是普通的goto語句。
程序流程在2個函數(shù)的半截里跳轉，就是長跳轉（long jmp）。
協(xié)程的原理如下：
1，當某個文件描述符需要IO等待的時候，通過長跳轉回到epoll的主框架函數(shù)，讓其他的IO可以運行。
2，當這個文件描述符的IO再次就緒之后，再通過長跳轉從主框架函數(shù)跳回來，接著上次的位置繼續(xù)運行：
這個位置，是函數(shù)上一次放棄運行的位置，它是函數(shù)內(nèi)的某個點。
在函數(shù)的半截里放棄CPU之后還能回來，就需要保存函數(shù)的運行上下文：棧信息、寄存器信息。
保存到哪里？
只能保存到堆上，因為棧和寄存器都會隨著代碼的運行而不斷地覆蓋，只有堆是受用戶控制的。
用戶測試代碼
上圖是“用戶代碼”，雖然兩個函數(shù)__async_connect()和__async_write()的內(nèi)部是異步執(zhí)行的，但它們都在一個函數(shù)_async_test()里，整個流程看上去是同步的。
__async_connect()函數(shù)，上半部
__async_connect()分為上半部和下半部，以__asm_co_task_yield()為分隔點。
上半部調用異步的connect()，下半部調用getsockopt()讀取結果。
為了避免阻塞線程，需要在異步connect()之后讓出CPU，讓主框架函數(shù)可以做別的。
這個讓出CPU的函數(shù)__asm_co_task_yield()，是“協(xié)程庫”的關鍵。
它讓出了CPU之后，在事件觸發(fā)之后再次恢復運行：這時函數(shù)__asm_co_task_yield()才會返回，然后接著運行下圖的代碼。
__async_connect()函數(shù)，下半部
當異步connect()成功時，getsockopt()獲取的錯誤碼err是0。
__async_write()函數(shù)
__async_write()函數(shù)的流程與__async_connect()類似，也是在文件描述符變得不可寫時放棄CPU，等待下次可寫時再恢復運行。
epoll主框架函數(shù)
epoll的主框架函數(shù)是一個while循環(huán)：使用epoll_wait()系統(tǒng)調用去監(jiān)控事件的觸發(fā)。
它會同時處理IO事件和定時器。
定時器的精度受限于epoll_wait()的等待時間。
epoll主框架函數(shù)
__scf_co_task_run()，可以讓“協(xié)程任務”首次運行，或者再次恢復運行。
_scf_co_task_run()函數(shù)
這個函數(shù)只是調用了__asm_co_task_run()，具體的長跳轉在匯編里實現(xiàn)。
因為長跳轉涉及到細致的內(nèi)存控制，只能用匯編實現(xiàn)。
運行結果：
要在本機上用命令nc -vv -l 2000當服務端。
打印的日志，是長跳轉時的棧信息的變化。
兩個匯編函數(shù)的大概功能，如下面的3張圖。
細節(jié)就不說了，這種代碼，時間久了連作者都快看不懂了[捂臉]
