one thread per connection 的好处和弱点

要实现一个并发的网络服务器，一个流行的做法是使用 one thread per connection 。
具体采用的模型可能是
《unix网络编程》 （第二版，中文版） 27.12 TCP预先创建线程服务器程序，主线程统一 accept 。

使用这种模型，有以下的好处：

1.可以很方便地把这个模型实现为一个与具体应用无关的 framework，
《unix网络编程》书上的代码稍加整理就已经是一个可重用的 server framework 了。
Page646 和 Page647 上面的代码，需要针对不同的应用做修改的，仅仅是 thread_main 函数中，对 web_child 的调用。
只需要重构这些代码，把 web_child 作为一个 callback function 参数，就能获得这个可重用的 server framework 了。

2.这种实现，首先保证了主线程只会阻塞在 accept 调用上，而不会被其他的情况阻塞，尤其是不会被具体的应用处理代码阻塞。
反过来说，就是实现应用代码的时候，可以直接使用会造成阻塞的操作，而不用担心会阻塞主线程。
目前使用的很多库都是阻塞型的，比如很多数据的客户端访问库（mysql，oracle，等）。
从这个角度来说，这个 server framework 是比较健壮的：无论应用代码如何实现，主线程还是按原定计划工作的。

3.阻塞型调用使开发者能够隐式地在线程的运行堆栈中，而不是在由开发者显示地管理的独立数据结构中维护状态信息和执行历史。


事物都有两面，这种模型也有以下的弱点：

在通常的实现中，创建一个线程的时候，同时都为线程保留了一个堆栈空间（在linux 2.4.18内核上，默认值是 2M）。
在 32bit 的机器上，按最大可用的 4G 地址空间来算，一个进程也只能有 2048 个线程。
在实际的环境中，通常很少有进程能够创建超过 512 个的线程，因为进程的地址空间通常还被动态分配的内存占用了很大一部分。
因此，这种模型通常很难同时处理超过 1000 个的并发连接。