（1）当系统负载较轻是，每来一个客户请求现场派生一个子进程为之服务的传统并发服务器程序模型就足够了。这个模型甚至可以与inetd结合使用，也就是inetd处理每个连接的接收。我们的其他意见是就重负荷运行的服务器而言的，譬如Web服务器。

（2）相比传统的每个客户fork一次设计示范，预先创建一个子进程池或一个线程池的设计示范能够把进程控制CPU时间降低10倍或以上。编写这些示范的程序并不复杂，不过以上没有给出例子的是：监视闲置子进程个数，随着所服务客户数的动态变化而增加或减少这个数目。

（3）某些实现允许多个子进程或线程阻塞在同一个accept调用中，另一些实现却要求包绕accept调用安置某种类型的锁加以保护。文件上锁或pthread互斥锁上锁都可以使用。

（4）让所有子进程或线程自行调用accept通常比让父进程或主线程独自调用accept并把描述符传递给子进程或线程来得简单而快速。

（5）由于潜在select冲突的原因，让所有子进程或线程阻塞在同一个accept调用中比让他们阻塞在同一个select调用中更可取。<<UNIX网络编程——客户/服务器程序设计示范（三）>>有说明。

（6）使用线程通常远快于使用进程。不过选择每个客户一个子进程还是每个客户一个线程取决于操作系统提供什么支持，还可能取决于服务每个客户需激活其他什么程序（若有其他程序需激活的话）。举例来说，如果accept客户连接的服务器调用fork和exec（譬如说inetd超级守护进程），那么fork一个单线程的进程可能快于fork一个多线程的进程。