C++ 協程與網絡編程

###協程 協程，即協做式程序，其思想是，一系列互相依賴的協程間依次使用CPU，每次只有一個協程工做，而其餘協程處於休眠狀態。協程能夠在運行期間的某個點上暫停執行，並在恢復運行時從暫停的點上繼續執行。 協程已經被證實是一種很是有用的程序組件，不只被python、lua、ruby等腳本語言普遍採用，並且被新一代面向多核的編程語言如golang rust-lang等採用做爲併發的基本單位。 協程能夠被認爲是一種用戶空間線程，與傳統的搶佔式線程相比，有2個主要的優勢：

• 與線程不一樣，協程是本身主動讓出CPU，並交付他指望的下一個協程運行，而不是在任什麼時候候都有可能被系統調度打斷。所以協程的使用更加清晰易懂，而且多數狀況下不須要鎖機制。
• 與線程相比，協程的切換由程序控制，發生在用戶空間而非內核空間，所以切換的代價很是的小。
• 某種意義上，協程與線程的關係相似與線程與進程的關係，多個協程會在同一個線程的上下文之中運行。

###網絡編程模型 咱們首先來簡單回顧一下一些經常使用的網絡編程模型。網絡編程模型能夠大致的分爲同步模型和異步模型兩類。

• 同步模型：

同步模型使用阻塞IO模式,在阻塞IO模式下調用read等IO函數時會阻塞線程直到IO完成或失敗。 同步模型的典型表明是thread_per_connection模型，每當阻塞在主線程上的accept調用返回時則建立一個新的線程去服務於新的socket的讀/寫。這種模型的優勢是程序邏輯簡潔，符合人的思惟；缺點是可伸縮性收到線程數的限制，當鏈接愈來愈多時，線程也愈來愈多，頻繁的線程切換會嚴重拖累性能，同時不得不處理多線程同步的問題。

• 異步模型：

異步模型通常使用非阻塞IO模式，並配合epoll/select/poll等多路複用機制。在非阻塞模式下調用read，若是沒有數據可讀則當即返回，並通知用戶沒有可讀（EAGAIN/EWOULDBLOCK），而非阻塞當前線程。異步模型可使一個線程同時服務於多個IO對象。 異步模型的典型表明是reactor模型。在reactor模型中，咱們將全部要處理的IO事件註冊到一箇中心的IO多路複用器中（通常爲epoll/select/poll），同時主線程阻塞在多路複用器上。一旦有IO事件到來或者就緒，多路複用器返回並將對應的IO事件分發到對應的處理器（即回調函數）中，最後處理器調用read/write函數來進行IO操做。

異步模型的特色是性能和可伸縮性比同步模型要好不少，可是其結構複雜，不易於編寫和維護。在異步模型中，IO以前的代碼（IO任務的提交者）和IO以後的處理代碼（回調函數）是割裂開來的。

###協程與網絡編程 協程的出現出現爲克服同步模型和異步模型的缺點，並結合他們的優勢提供了可能： 如今假設咱們有3個協程A,B,C分別要進行數次IO操做。這3個協程運行在同一個調度器或者說線程的上下文中，並依次使用CPU。調度器在其內部維護了一個多路複用器（epoll/select/poll）。 協程A首先運行，當它執行到一個IO操做，但該IO操做並無當即就緒時，A將該IO事件註冊到調度器中，並主動放棄CPU。這時調度器將B切換到CPU上開始執行，一樣，當它碰到一個IO操做的時候將IO事件註冊到調度器中，並主動放棄CPU。調度器將C切換到cpu上開始執行。當全部協程都被「阻塞」後，調度器檢查註冊的IO事件是否發生或就緒。假設此時協程B註冊的IO時間已經就緒，調度器將恢復B的執行，B將從上次放棄CPU的地方接着向下運行。A和C同理。 這樣，對於每個協程來講，它是同步的模型；可是對於整個應用程序來講，它是異步的模型。

好了，原理說完了，咱們來看一個實際的例子，echo server。

###echo server

在這個例子中，咱們將使用orchid庫來編寫一個echo server。orchid庫是一個構建於boost基礎上的 協程/網絡IO C++庫。

echo server首先必需要處理鏈接事件，咱們建立一個協程來專門處理鏈接事件：

typedef boost::shared_ptr<orchid::socket> socket_ptr;
//處理ACCEPT事件的協程
void handle_accept(orchid::coroutine_handle co) {
    try {
        orchid::acceptor acceptor(co -> get_io_service());//構建一個acceptor
        acceptor.bind_and_listen("5678",true);
        for(;;) {
            socket_ptr sock(new orchid::socket(co -> get_scheduler().get_io_service()));
            acceptor.accept(*sock,co);

            //在調度器上建立一個協程來服務新的socket。
            //第一個參數是要建立的協程的main函數，
            //第二個參數是要建立的協程的棧的大小。
            co -> get_scheduler().spawn(boost::bind(handle_io,_1,sock),orchid::minimum_stack_size());
        }
    }
    catch(orchid::io_error& e) {
        ORCHID_ERROR("id %lu msg:%s",co->id(),e.what());
    }
}

在orchid中，協程的main函數必須知足函數簽名void(orchid::coroutine_handle)，如handle_accept所示，其中參數co是協程句柄，表明了當前函數所位於的協程。

在上面的代碼中，咱們建立了一個acceptor，並讓它監聽5678端口，而後在"阻塞"等待鏈接到來，當鏈接事件到來時，建立一個新的協程來服務新的socket。處理套接字IO的協程以下：

//處理SOCKET IO事件的協程
void handle_io(orchid::coroutine_handle co,socket_ptr sock) {
orchid::buffered_reader<orchid::socket> reader(*sock,co,16);//在socket上構建緩衝輸入流
orchid::buffered_writer<orchid::socket> writer(*sock,co,16);//在socket上構建緩衝輸出流

try {
    std::string line;
    std::size_t n = 0;

    for(;;) {
        n = reader.read_until(line,'\n');
        ORCHID_DEBUG("id %lu recv: %s",co->id(),line.c_str());
        writer.write(line.c_str(),line.size());
        writer.flush();
    }

} catch (const orchid::io_error& e) {
    if (e.code() == boost::asio::error::eof) {
        ORCHID_DEBUG("id %lu msg:%s",co->id(),"socket closed by remote side!");
    } else {
        ORCHID_ERROR("id %lu msg:%s",co->id(),e.what());
    }
}

IO處理協程首先在傳入的套接字上建立了一個輸入流和一個輸出流，分別表明了TCP的輸入和輸出。而後不斷地從輸入流中讀取一行，並輸出到輸出流當中。當socket上的TCP鏈接斷開時，會拋出orchid::io_error的異常，循環結束，值得注意的是eof事件也被當成異常來拋出。對於不喜歡使用異常的用戶，orchid提供了另一套使用boost::system::error_code的接口。同時，對於熟悉asio的用戶，orchid提供了一套boost asio風格的接口。

若是用戶須要無緩衝的讀寫socket或者自建緩衝，能夠直接調用orchid::socket的read和write函數，或者使用無緩衝的reader和writer。

細心的讀者可能已經發現，handle_io的函數簽名並不知足void(orchid::coroutine_handle)，回到handle_accept中，能夠發現，實際上咱們使用了boost.bind對handle_io函數進行了適配，使之符合函數簽名的要求。

最後是main函數：

int main() {
    orchid::scheduler sche;
    sche.spawn(handle_accept,orchid::coroutine::minimum_stack_size());//建立協程
    sche.run();
}

###總結 在上面這個echo server的例子中，咱們採用了一種 coroutine per connection 的編程模型，與傳統的 thread per connection 模型同樣的簡潔清晰，可是整個程序實際上運行在同一線程當中，因此咱們也不須要處理多線程同步的問題。 因爲協程的切換開銷遠遠小於線程，所以咱們能夠輕易的同時啓動上千協程來同時服務上千鏈接，這是 thread per connection的模型很難作到的；在性能方面，整個底層的IO系統其實是使用boost.asio這種高性能的異步io庫實現的。與IO所費的時間相比，協程切換的開銷基本能夠忽略。 所以經過orchid，咱們能夠在保持同步IO模型簡潔性的同時，得到異步IO模型的高性能和擴展性。

最後，若是您對orchid感興趣，歡迎關注和參與。