而且该信号量应使用与asio相同的信号量。
回复 19# cobras
async cancelation永远是不可靠滴，即使在Windows下，很多async cancelation操作也需要底层支持，并不能保证可用性。
另外，fd经过async cancelation操作之后，不能保证能继续使用。
回复 1# windoze
下次用tcpcopy压测一下，200k QPS 很厉害
你好，我对fiberized.io 挺有兴趣。想试用一下。但我不知道它能不能适应我的应用场景。
我的服务在收到请求后还要和其他的几个服务交互才会完成工作。而我又不想在处理每一个请求的时候都去新建一个tcpstream去连接其他的服务并完成交互。我希望各个服务之间的连接是相对固定的（可以是连接池，也可以是每个线程有一个专用的连接）。如我所愿的话，就会存在多个请求（fiber）共用一个连接去和其他服务交互的情况。不知道fiberized.io能不能应付这种情况。
例如：N个请求通过一个连接去和另一个服务交互，每个请求都一个自己的req_id, 在向另一个服务发送请求的时候带上这个req_id. 当收到响应的时候根据req_id找到对应的请求然后继续执行。fiberized.io能解决这个问题吗？
回复 23# dive_
这种场景你可以用连接池，无论是std::thread还是fibio::fiber其实方法都是一样的。
建立一个跨thread/fiber共享的list，里面保存所有已经建立的连接，当你需要获得一个连接时，从这个list里取出一个来，用完了再放回去。
如果list是空的，你有两种选择，一是创建一个新连接，但这样可能会导致服务端连接太多；要不然就等待其它人归还一个连接。如果是后者，你需要在这个list上应用一些同步机制，fiberized.io里有一个concurrent_queue可以用来干这个（这是一个模板类，同时适用于std::thread和fibio::fiber），需要的时候从queue里pop一个，用完了再push回去，pop的时候如果队列空则一直等待到有人push为止。
对比std::thread，fiberized.io的主要优势在于提高并发能力，尤其是对于app server层，因为这一层往往需要在处理客户端请求的同时访问各种后端的服务，自身的计算任务比较少，如果使用std::thread，可能你需要创建很多个才能让负载能力达到要求（Tomcat缺省配置是500），但这样会导致大量的thread context switch，而fiber的切换成本低很多，所以在这种场景里效率会比较高。
回复 1# windoze
真 V5 {:3_189:}
Win32/MinGW 环境能用么，刚刚调通 Win32/MinGW 环境下 Apache Thrift 的 TNonblockingServer。 不过我目前也不需要很多并发，最多几百个，桌面项目，不是服务器。
回复 25# zhujiang73
因为我手头没有可用的Windows机器，所以目前应该还不行。
不过因为Fiberized.IO所用的所有基础组建都支持Windows，所以应该工作量不大，只要找到开发机要不了几天……
回复 24# windoze
谢谢，我会尝试一下，搞定以后向你报告。
楼主棒棒哒。
我们做web，就是用类似的思想，nginx加lua顺序代码全异步。
windoze 发表于 2014-03-21 16:09 static/image/common/back.gif
如果你习惯于写每连接一个线程的程序，那试试这个吧 Fiberized.IO
你可以继续使用原来的模型，只需要把thr ...
怎么make？