返回信息流如题。各有哪些优缺点，和适用场景。看了一些博客还是不太明白。
这是一条镜像帖。来源：北邮人论坛 / cpp / #97624同步于 2018/5/27
该镜像源已超过 30 天没有更新，可能在源站已被删除。
CPP机器人发帖
实现并发服务器，IO复用模型、多线程和多进程之间如何选择，遵
corner
2018/5/27镜像同步20 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
1、如果计算响应的工作量远大于fork()的开销，这种适合长连接。可以对每个客户新建一个子进程。
2、对每个客户新建一个线程。
3、优化1，对accept现象的经群考虑。
4、对方案2的优化。
以上都是阻塞式网络编程，程序会阻塞在read()上，等待数据到达。
5、单线程Reactor方案。但是IO和计算都在同一个线程。
6、在5的基础上每个IO创建一个线程去计算（可以用线程池优化），原来的线程进行IO。
7、在6基础上用线程池，IO在Reactor线程完成，计算交给thread pool。
8、one loop per thread方案。一个Reactor线程负责accept连接，在线程池中选择一个线程去处理这个IO和计算。与7相比，由于7所有的io在Reactor中完成，8减少了线程的切换。
9、7和8混合。
感谢！感谢！
【 在 ym19940508 (【意涵团】噗噗噗) 的大作中提到: 】
: 1、如果计算响应的工作量远大于fork()的开销，这种适合长连接。可以对每个客户新建一个子进程。
: 2、对每个客户新建一个线程。
: 3、优化1，对accept现象的经群考虑。
: ...................
请问这是你总结的还是在哪本书上看到的，想系统的学习一下。
【 在 ym19940508 (【意涵团】噗噗噗) 的大作中提到: 】
: 1、如果计算响应的工作量远大于fork()的开销，这种适合长连接。可以对每个客户新建一个子进程。
: 2、对每个客户新建一个线程。
: 3、优化1，对accept现象的经群考虑。
: ...................
emmm，感觉你说的6和7就是Proactor模式吧。IO线程读取完，把请求放入线程池队列中，由线程池处理请求。这种方式一般是用epoll的et模式，可能需要多次read才能读取完毕，然后把读取的内容封装成对象塞入线程池队列。
【 在 ym19940508 (【意涵团】噗噗噗) 的大作中提到: 】
: 1、如果计算响应的工作量远大于fork()的开销，这种适合长连接。可以对每个客户新建一个子进程。
: 2、对每个客户新建一个线程。
: 3、优化1，对accept现象的经群考虑。
: ...................
通过『我邮2.0』发布
另外，Linux2.6上貌似已经没有accept的惊群问题了。
【 在 ym19940508 (【意涵团】噗噗噗) 的大作中提到: 】
: 1、如果计算响应的工作量远大于fork()的开销，这种适合长连接。可以对每个客户新建一个子进程。
: 2、对每个客户新建一个线程。
: 3、优化1，对accept现象的经群考虑。
: ...................
通过『我邮2.0』发布
弱弱问一下，你说的工作模式是每个线程处理一个连接的工作事务吧？
能否说说每个线程处理多连接的
【 在 ym19940508 的大作中提到: 】
: 1、如果计算响应的工作量远大于fork()的开销，这种适合长连接。可以对每个客户新建一个子进程。
: 2、对每个客户新建一个线程。
: 3、优化1，对accept现象的经群考虑。
: ...................
其实和Proactor还是有差别的啊，我理解Proactor是遇到了阻塞的系统调用比如read，系统帮你read完之后告诉你读完了，但是这里面除了read还有计算。思想和Proactor差不多。
【 在 wjy1230 的大作中提到: 】
: emmm，感觉你说的6和7就是Proactor模式吧。IO线程读取完，把请求放入线程池队列中，由线程池处理请求。这种方式一般是用epoll的et模式，可能需要多次read才能读取完毕，然后把读取的内容封装成对象塞入线程池队列。
:
: 通过『我邮2.0』发布