CppExplore

blessing

能得出上面的结论，可能有下面几个原因：
1、在学会了数据结构之后，至今还没学会STL，至少对STL没有全面的认识
2、在复杂程序的数据结构面前，不能灵活应用学过的数据结构的精髓：思想
3、尚未系统的学习c++库
4、尚未写过大型的应用层程序
5、对哲学没有深入的思考。看问题片面，主观性强。

吾生也有涯,尔知也无涯。共勉！

无头链表使用起来，问题多多。

面试官不够宽容，面试者比较倔。峣峣者易折,佼佼者易污。共勉！
如果你是面试官，你会怎样安排面试题目，如何在有限的时间里考察一个人呢？
如果你是面试者，你希望被如何面试，如何在有限的时间里展示自己的优点呢？

@true
：）
这个就是文中2（1）的模型，主线程accept，将新的clientfd通过管道传递给epoll线程，管道的读端也在epoll的监控之下。不使用管道的话，sockpair也可以，不过它也是基于管道实现。
管道的连接是不可回避的，因为epoll线程在epoll_wait处等待，要实时的告诉epoll监控某fd，一定要epoll_wait返回，执行加入操作，再继续epoll_wait。
后面的业务线程处理也就是2（4）和2（5）模型。
2（3）是单线程的模型，就epoll而言，单线程的性能最好，也就是epoll+单线程=高性能。业务线程当然是根据需要后接线程，测试的数据一直没时间发出来，过几天发下。

@true
可以在上一篇《网络模型二》http://www.cppblog.com/CppExplore/archive/2008/03/21/45061.html中跟贴讨论新模型，是文中已有的，还是没有的新模型，本文旨在讨论函数本身的差异。
epoll和线程池的结合，不是很理解，是epoll单线程后接业务线程，还是epoll本身线程池？epoll本身的话，我想象不出来，结构在可读状态的话，新线程epoll_wait还是可读。并且线程池要求无内蕴状态，行为的变化来自于外界的输入参数，莫非是《网络模型二》中的模型2（1）？
就epoll而言，《网络模型二》的2模型中，业务线程先不谈，单线程的epoll性能就很强，其他模型的测试结果反而有下降。poll/select则不同。
这个话题最好还是在《网络模型二》中探讨，本文不多扩展。

removed!

@菌子
个人做过.net、java、c、c++的项目，谈点个人的看法：net和java相比，想不出任何的优势来，跨平台net不行，开源方面net不行，java社区的活力net更是不及，java几乎可以统一企业级的上层应用业务开发。
应用服务器、游戏服务器、图形方面还是c++的强项，性能、稳定性、语言特性、低层库的支持，其它语言还是难以竞争吧。追逐高性能、高并发高吞吐量的服务器领域，也不是java能与之竞争的。
个人做的c项目一样可以换成c++来开发，c能胜任，c＋＋不能胜任的 可能就是c++编译器不能触及的地方吧，暂时想不出来。

欢迎 等你好文章啊

它使用Apache License。允许免费修改重发布，允许商业使用，允许不公布修改后的源代码。

/usr/include/sys/queue.h

@zoyi
红黑树就是二叉平衡树的调整版本 std::map就可以作为实现用。
呵呵 有第一个就会有第二个、第三个........

能从二分过渡过去的，怎么也不应该想到用hash啊，直接想到的也应该是红黑树。主键是字符串除外

3个参数的是strncpy
就空间存储而言，还是用memcpy类函数
另因为string内存布局的不透明性，用memcpy也是不明智的选择，更遑论存储空间的连续性问题了。
就strcpy而言，取string的c_str()一定是没问题的。

mfc吓退了一大批的程序员，带坏了一大批程序员，害人不浅啊。

所有人共同努力的结果，最后有其中的一人整理成论文而已吧

removed by cppexpore

那里没有我心目中的标准答案 遗憾啊 呵呵

HijackThis.exe

精彩！多多发点这种造福大众的文章啊！

@Fox
呵呵，不同的经验能得出不同的看法。
我觉得这种题目，查表法不仅不是“奇技淫巧”，反而是最完美的方法。

就像经常见的面试题：给定一个unsigned char类型变量，输出按位反转后的值，比如0x2A=00101010 反转后就是01010100=0x54

猜猜这个题目的标准答案是什么啊，呵呵，查表法。如果反对，请给出一个比这个还高效的算法。

最简单的方法是先写个效率低下的程序，把所有结果打印出来。
然后写个程序，把结果存在一个表里，用查表法，扫描整个表，挨个打印出来。

当然也可以一个变量不用，直接把上个程序的输入结果，打印下。不过这样就没意义了。实际的应用一定是需要其中的结果，而查表是最实用的。

果然够草

不错不错！
思维很活跃，文笔也很好。

好文，多写点这种类型的。
工欲善其事，必先利其器

呵呵 再多写几个月就好了，也就是等写到麻木就好了。

呵呵，以前写c语言常用的方法。
c语言中，指针在结构体里的使用，真是非常的精巧。

多谢提醒，2的问题还真是遗漏了，1的问题的确也应该考虑，呵呵

附一个我实现的线程消息队列：http://www.cppblog.com/CppExplore/archive/2008/03/20/44949.html
消息类型的申请释放配合小对象内存池，完美的解决方案

既然是传递指针进消息队列，取端进行free，想必是同一进程间的通讯吧。
为什么要用ipc的消息队列呢，很笨重，自己写线程消息队列性能更高，简直不是一个数量级的。

赞一个，很系统，等待你的测试驱动开发方案的ppt，：）

嘿嘿，可以得分滴。不过刷新分数有间隔的，并不是实时的。

期待中......
看来是一个更高一级的封装，考虑的东西更多更复杂。公布出来一定拜读。

公布的源码放首页好吗？这个让读者看了没什么收获啊

@eXile
第三方库中的定时器实现还没看呢，以后有时间整理下。最近是不准备研究了。

@kw
呵呵，想了下，真是不高啊。
直接保存gettimeoftime（）＋interval的时间做间隔，并在LIST中排序应该是最好的方法。

@Colin
呵呵，你的精度要求太高了。零点了，该睡了。8888

@Colin
你可真快啊，我有个习惯：把写的丢失，中途会提交，然后再修改再提交直到结束。最后写完，就已经有回复了，呵呵。
精度问题，只能在系统能力之内尽量了，一般的应用server非实时性很强的系统需要不了微秒级的精度，我的实际应用秒级够了。

@创
呵呵，不奇怪啊。我压根就没看stl的内存池，ACE的看了，果然是集大成者，到是想写呢，后来写多了加上去写其他方面的 就懒了。
现在网络模型的也是写了一半，下一篇估计就是去写定时期了，呵呵

@创
你看的第一篇吧，对于小对象后面的loki和boost都不错的。
不要浪费精力研究了，就是一个结构，原理都很简单，看的太仔细了也是没什么意思，呵呵。

http://www.cppblog.com/CppExplore/archive/2008/02/18/42890.html
http://www.cppblog.com/CppExplore/archive/2008/02/19/42952.html
http://www.cppblog.com/CppExplore/archive/2008/02/20/42986.html

没什么算法，结构决定了算法。

系统调用不检查返回值？系统没有log机制？
监控一个冲突一个的话，还有什么监控的必要。
这些端口没什么区别，linux上1024下的是预留端口，需要root帐号才能bind。
bind成功的标志就是bind函数返回成功，呵呵。

@RichardHe
随意 很宽松
至少要言之有物，让别人看了有点收获。
当然个人的主观偏见也是避免不了的。

呵呵，你还真执着，又挪首页来了，莫非是我上次移处失败？

留言是这个：“文章《周二》移出1.首页原创精华区 ”。
多多理解、配合！

登陆后在你的后台管理页面有一个查看“留言”，那里面。

每天写工作日志是个好习惯！
请关注下私人留言。

@suxiaojack
呵呵 一语中的！文中的内容的确不是技巧，都是能优雅解决实际问题的东东

@xushiwei
“它是基础设施，那么它的性能调优是非常关键的”，这句话我不反对，虽然我认为对变长内存池没必要。不过你的测试代码并没有反映apr_pool的真实性能。

@ecopgm
这么晚还没睡觉啊。
这里说的爆发的连接，也可以说是单点并发。你想的并发是不是同时在线的连接啊？一般都是追求的同时在线连接数。爆发连接的场景毕竟也不多。尤其是对音频视频等多媒体的应用服务器，限于网络带宽，也不可能有爆发的连接出现，有的话直接拒绝连接就可以接受，呵呵。

@ecopgm
1、上面的模型并不是都将accept独立处理啊？各种情况都有的。“下级线程池处理逻辑”这个就多说了，这个和accept/读写是否在同一线程不冲突，不同线程的时候也可以把逻辑独立出来。各种模型性能上的数据对比后面的文章会给出具体的数据。概括说下，不单独处理accept，除epoll方式外，爆发连接都会出现拒绝连接情况，比如ab（apache带的工具）并发1w的时候。当然并非所有的服务器能是要处理这种爆发的断连接。在不拒绝连接的情况下，比如并发1000，性能还是差不多的。
2、连接被拒绝是在三路握手阶段，accept接受的所有连接，连接就不会被丢掉了啊，生产者的确是非常快，消费者很慢，但不影响client把数据发送到这边的接受缓冲区。服务器没有发送reset的必要，client也不会发fin分节，连接自然不会被丢掉。
3、消息队列自然比管道快，这里的消息队列不是ipc的消息队列，全部实现在用户态，可以看下上一篇《线程二》有消息队列的实现，比涉及系统调用的管道快，管道怎么也是属于进程间通讯的方式。但是消息队列不能象管道一样把文件描述符放到fd_set里，供select监控。