主题：【原创】进程的反击 -- zllwy

cgi，那是多么古老的技术啊。所以我说进程又回来了，而不是出现啊。而且cgi是个协议，跟进程没有必然联系。

说到server端的并发技术，也是很有意思的一个问题。早期的web server是用process，比如apache（当然现在也通过模块支持线程了）。然后threading成为主流。但thread对于server的大量并发请求还是不够细，操作系统只能支持有限的threads，著名的c10k问题就是关于这个的。很多模型出现了，比如SEDA，event-driven。目前event-driven是最流行的，因为event-driven不需要维护thread的context（register, stack等等），少量的thread就可以对付大量的并发请求。很多AIO（异步I/O）的程序库应运而生，比如Java NIO，Netty，libevent(C)。现在特别热火的Node.js（用javascript写的web server）也是event-driven。不过，event-driven在编程上比较难写而且容易出错，是我很讨厌的一种模式。我比较看好Actor/message passing或者CSP之类的并发编程技术，erlang是最早在这方面探索的。基本想法就是并发的粒度进一步减少，这样就不受thread limit的限制。这就是所谓的coroutine。coroutine依靠合作的方式进行切换，需要比较小的stack。coroutine之间的同步可以采用message passing。message passing和share memory是等效的，但相对于thread的传统同步方式，message passing比较容易写，而且不容易出错。目前有很多新的编程语言在探索这种方式，或者改进现有的语言来支持。比如scala，kilim，和我目前最喜欢的语言Go。Go的goroutine就是类似于coroutine的实现，多个goroutine被map到有限的几个线程上去（基本上就等于你机器有的cpu core的数量就可以了）。goroutine之间用channel来传递消息。一个程序可以生成大量的goroutine，这样我们就又可以回到同步，顺序的方式来写server了。所以用Go来写networking的程序是最容易的。所以在server端，基本趋势就是并发的粒度越来越小。我还没有看到有回到process的必要。

至于GIL是python设计的一大缺陷，但这不以为着python是基于进程的，python也是有thread的，只是有GIL这个bottleneck，限制了并发的程度。另外，python 3这个问题好像已经解决了。