就象是一个tcp服务器,从几个不同的连接接收数据,我看了些样例，linux中都是要将连接fork成子进程，那么子连接接收的数据必定是在子进程当中，这样几个子进程再将数据进行组合（比如统一由父进程来处理），应该是要使用共享内存来做。

不知道有没兄弟知道这个的比较成熟的做法，我的思路是否正确？

同意楼上,用什么方法实现还是要根据你的实际情况,如果客户端少,连接时间长的话推荐使用fork,安全稳定.CLIENT数目有最大数值的（不是越多越好的），连接时间比较长的这一类服务，用多THREAD几乎没有什么意义。 THREAD的优势是创建开始运行比进程快些（pthread_create比fork), 一旦运行起来，进程的切换和thread的切换差别没有什么。调度也都按进程做的。
THREAD因为共享了内存使得物理内存节省。然而进程本身也有共享的物理页（比如共享库部分）。
还有一开始用多THREAD在那里等着（池）。对于连接数量小并且固定的服务意义不大。正是因为共享内存，使得多THREAD程序的调试麻烦，运行稳定性不如进程。所以我建议，能不用THREAD尽量不用。如果必须用，也可以先不用--用进程，等都调试好了后在改THREAD。也不晚。

正确,我这里处理消息量每天都在几千万,就是这种方式.子进程的优势在于可以一直保持服务端的端口稳定,不会因为进程处理消息意外core掉而影响其他客户端的服务

并发量不是很大的话，或者对处理时间要求不严的情况下 单进程select或者poll就可以了，不用太复杂
并发量大的情况下肯定要用到多进程，进程间传递数据的方式有很多， 不一定要用共享内存，个人觉得消息队列比较好用，不用自己做互斥，呵呵

如果是这种情况，我倒是建议楼主将接收和整合部分分开成两个独立的程序模块，两个程序模块间可以使用各种IPC进行通讯（比如消息队列，也可以使用第三方的中间件交互），接收的只接收，整合的只整合，这样会更便于以后扩展，也更符合unix下的设计思想。

不妨使用多线程，这样就没有进程间通信的麻烦了。