Win32多线程之为什么不使用多进程

    人们一旦接触到线程，他们最常问的问题就是：有什么是线程能够给我而多进程所不能给我的？言下之意就是，线程又怎么样！最重要的答案便是：线程价廉，线程启动比较快，退出比较快，对系统资源的冲击也比较小，而且，线程彼此分享了大部分核心对象（如 file handles）的拥有权。

   如果使用多重进程，最困难的问题大概是：如何把窗口的handle交给另一个进程，在Win32中，handle只在其诞生地（进程中）才有意义。这好似一种安全警戒，避免某个进程危及另一个进程的资源。为了分享窗口的handle，你必须明明白白地产生该handle的一个副本，并且可以被其他进程使用。在一个多线程程序中，所有线程都可以使用这个窗口hadle,因为handle和线程生活在同一个进程之中。

   即使完全不需要窗口的情况下，例如服务器软件似乎应该是多进程的爱好者，毕竟在同一个服务器上每个用户做的事情不尽相同。除了少数例外，进来的每一个请求完全与其他的请求无关联，而且，每一个请求通常只带有少量数据。

  虽然，为每个请求产生一个新的进程也很容易，但其额外负担非常惊人：必须载入服务器软件的一个全新副本，配置大量内存并初始化，新的副本必须将状态调整到与原先状态相同，数秒钟可能就这样过去了-----在这么忙碌的服务器上，新的进程在准备好为了这个请求的8KB数据服务，而任务完成后每一样东西又必须拉下马来。为了搬移这8KB数据，要做太多事，操作系统内部必须操作好几MB的内存才能为此请求服务。

   如果你以单一线程为所有的请求服务，你就无法获得硬件的最佳使用率。如果有许多个线程，就可以令某些线程等待系统资源，如网络和硬盘，操作系统可以很有效率地处理这些请求，因为它可以在任何时刻都知道谁正在等待什么，并决定怎样调整最好，如果只有单一线程，要让硬件充分发挥性能就很困难了。如果线程必须 做任意大面积的计算，所有其他的请求都必须都必须等待！

  在客户/服务器环境中的另一个极端，是所谓的工作组数据库服务器。可能会有一些用户对它产生连接（connection）并持续数小时之久，这种情况下产生的个别的进程以服务个别的用户不算什么。但不幸的是，每个人还是使用同一个数据库，所以进程之间还是必须商议，看谁可以读一笔数据或写一笔数据，或改变一个索引，这和我们面对线程时遭遇的问题一样，只不过现在更复杂，因为要共享的是跨越进程的数据结构，如果使用线程，则程序的所有内存全由其线程共享。