在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::tcp_ostream out(*sock,co);
orchid::tcp_istream in(*sock,co);
for(std::string str;std::getline(in, str) && out;) {
out<
}
}
IO处理协程首先在传入的套接字上创建了一个输入流和一个输出流,分别代表了TCP的输入和输出。然后不断地从输入流中读取一行,并输出到输出流当中。当socket上的TCP连接断开时,输入流和输出流的eof标志为会被置位,因此循环结束,协程退出。
orchid可以使用户以流的形式来操作套接字。输入流和输出流分别提供了std::istream和std::ostream的接口;输入流和输出流是带缓冲的,如果用户需要无缓冲的读写socket或者自建缓冲,可以直接调用orchid::socket的read和write函数。但是需要注意这两个函数会抛出boost::system_error异常来表示错误。
细心的读者可能已经发现,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所费的时间相比,协程切换的开销基本可以忽略。
因此通过协程,我们可以在保持同步IO模型简洁性的同时,获得近似于异步IO模型的高性能。
22/2<12