在異步操作里，如異步連接、異步讀寫之類的協程，co_await這些協程時需要注意線程切換的細節。

以asio異步連接協程為例：

class client {
public:
    client() {
        thd_ = std::thread([this]{
            io_ctx_.run();
        });
    }

    async_simple::coro::Lazy<bool> async_connect(auto host, auto port) {
        bool ret = co_await util::async_connect(host, port);  #1
        co_return ret;      #2                                 
    }

    ~client() {
        io_ctx_.stop();
        if(thd_.joinable()) {
            thd_.join();
        }
    }

private:
  asio::io_context io_ctx_;
  std::thread thd_;
};

int main() {
    client c;
    async_simple::coro::syncAwait(c.async_connect());
    std::cout<<"quit\n"; #3
}

這個例子很簡單，client在連接之后就析構了，看起來沒什么問題。但是運行之后就會發生線程join的錯誤，錯誤的意思是在線程里join自己了。這是怎么回事？co_await一個異步連接的協程，當連接成功后協程返回，這時候發生了線程切換。異步連接返回的時候是在io_context的線程里，代碼中的#1在主線程，#2在io_context線程，之后就co_return 返回到main函數的#3，這時候#3仍然在io_context線程里，接著client就會析構了，這時候仍然在io_context線程里，析構的時候會調用thd_.join(); 然后就導致了在io_context的線程里join自己的錯誤。

這是使用協程時容易犯錯的一個地方，解決方法就是避免co_await回來之后去析構client，或者co_await回來仍然回到主線程。這里可以考慮用協程條件變量，在異步連接的時候發起一個新的協程并傳入協程條件變量并在連接返回后set_value，主線程去co_await這個條件變量，這樣連接返回后就回到主線程了，就可以解決在io線程里join自己的問題了。

還是以上面的異步連接為例子，需要對之前的async_connect協程增加一個超時功能，代碼稍作修改：

class client {
public:
    client() : socket_(io_ctx_) {
        thd_ = std::thread([this]{
            io_ctx_.run();
        });
    }

    async_simple::coro::Lazy<bool> async_connect(auto host, auto port, auto duration) {
        coro_timer timer(io_ctx_);
        timeout(timer, duration).start([](auto&&){}); // #1 啟動一個新協程做超時處理
        bool ret = co_await util::async_connect(host, port, socket_);//假設這里co_await返回后回到主線程
        co_return ret;                                      
    }

    ~client() {
        io_ctx_.stop();
        if(thd_.joinable()) {
            thd_.join();
        }
    }


private:
  async_simple::coro::Lazy<void> timeout(auto &timer, auto duration) {
    bool is_timeout = co_await timer.async_wait(duration);
    if(is_timeout) {
        asio::error_code ignored_ec;
        socket_.shutdown(tcp::socket::shutdown_both, ignored_ec);
        socket_.close(ignored_ec);
    }

    co_return;
  }

  asio::io_context io_ctx_;
  tcp::socket socket_;
  std::thread thd_;
  bool is_timeout_;
};

int main() {
    client c;
    async_simple::coro::syncAwait(c.async_connect("localhost", "9000", 5s));
    std::cout<<"quit\n"; #3
}

這個代碼增加連接超時處理的協程，注意#1那里為什么需要新啟動一個協程，而不能用co_await呢？因為co_await是阻塞語義，co_await會導致永遠超時，啟動一個新的協程不會阻塞當前協程從而可以去調用async_connect。

當timeout超時發生時就關閉socket，這時候async_connect就會返回錯誤然后返回到調用者，這看起來似乎可以對異步連接做超時處理了，但是這個代碼是有問題的。假如異步連接沒有超時會發生什么？沒有超時的話就返回到main函數了，然后client就析構了，當timeout協程resume回來的時候client其實已經析構了，這時候再去調用成員變量socket_ close將會導致一個訪問已經析構對象的錯誤。

也許有人會說，那就在co_return之前去取消timer不就好了嗎？這個辦法也不行，因為取消timer，timeout協程并不會立即返回，仍然會存在訪問已經析構對象的問題。

正確的做法應該是對兩個協程進行同步，timeout協程和async_connect協程需要同步，在async_connect協程返回之前需要確保timeout協程已經完成，這樣就可以避免訪問已經析構對象的問題了。

這個問題其實也是異步回調安全返回的一個經典問題，協程也同樣會遇到這個問題，上面提到的對兩個協程進行同步是解決方法之一，另外一個方法就是使用shared_from_this，就像異步安全回調那樣處理。

還是以異步連接為例：

async_simple::coro::Lazy<bool> async_connect(const std::string &host, const std::string& port) {
    co_return co_await util::async_connect(host, port);
}

async_simple::coro::Lazy<void> test_connect() {
    bool ok = co_await async_connect("localhost", "8000");
    if(!ok){
        std::cout<<"connect failed\n";
    }

    std::cout<<"connect ok\n";
}

int main() {
    async_simple::coro::syncAwait(test_connect());
}

這個代碼簡單明了，就是測試一下異步連接是否成功，運行也是正常的。如果稍微改一下test_connect：

async_simple::coro::Lazy<void> test_connect() {
    auto lazy = async_connect("localhost", "8000");
    bool ok = co_await lazy;
    if(!ok){
        std::cout<<"connect failed\n";
    }

    std::cout<<"connect ok\n";
}

很遺憾，這個代碼會導致連接總是失敗，似乎很奇怪，后面發現原因是因為async_connect的兩個參數失效了，但是寫法和剛開始的寫法幾乎一樣，為啥后面這種寫法會導致參數失效呢？

原因是co_await一個協程函數時，其實做了兩件事：

• 調用協程函數創建協程，這個步驟會創建協程幀，把參數和局部變量拷貝到協程幀里；

• co_await執行協程函數；

回過頭來看auto lazy = async_connect("localhost", "8000"); 這個代碼調用協程函數創建了協程，這時候拷貝到協程幀里面的是兩個臨時變量，在這一行結束的時候臨時變量就析構了，在下一行去co_await執行這個協程的時候就會出現參數失效的問題了。

co_await async_connect("localhost", "8000"); 這樣為什么沒問題呢，因為協程創建和協程調用都在一行完成的，臨時變量知道協程執行之后才會失效，因此不會有問題。

問題的本質其實是C++臨時變量生命周期的問題。使用協程的時候稍微注意一下就好了，可以把const std::string&改成std::string，這樣就不會臨時變量生命周期的問題了，如果不想改參數類型就co_await 協程函數就好了，不分成兩行去執行協程。