大家都知道，应用层的网络模型有同步、异步之分。
同步，意为着线程阻塞，只有等本次请求全部都完成了，才能进行下一次请求。
异步，好处是不阻塞当前线程，可以“万箭齐发”的将所有请求塞入缓冲区，然后谁的请求先完成就处理谁。
大家也注意到了，同步模式阻塞的只是“线程”。实际上，在异步模式流行之前，人们也经常用多线程的方式处理并发请求。然而，随着数据规模的不断加大，线程开销所带来的CPU、内存剧增，因此这种方法的应用比较有限。
近几年来，随着异步处理方案在node.js、Nginx等系[......]
fork()之后，子进程和父进程分叉执行，僵尸进程的产生是因为父进程没有给子进程“收尸”造成的，又可以根据危害程度分为下述两类：
总体来说：当子进程结束之后，但父进程未结束之前，子进程将成为僵尸进程。
（1）当子进程结束之后，但父进程未结束之前，子进程将成为僵尸进程，父进程结束后僵尸被init进程回收。
（2）如果子进程结束了，但是父进程始终没有结束，那么这个僵尸将一直存在，而且随着exec，僵尸越来越多。
传统的方法是在parent中使用wait()等待子进程直到回收，但是这样就会一直阻塞，父进程什么都作不了了！
有没有别的方法呢？有！那就是使用waitpid()＋Signal的方法实现异步干掉僵尸进程。
原理：
(1)子进程退出的时候，会发送一个信号：SIGCHLD
(2)使用signal()可以指定程序处理某个信号量的对应handle函数
内附源代码。[......]
epoll是Kernel 2.6后新加入的事件机制，在高并发条件下，远优于select.
用个硬件中的例子吧，可能不太恰当：epoll相当于I／O中断（有的时候才相应），而select相当于轮询（总要反复查询）。
其实epoll比slect好用很多，主要一下几个用法。
struct epoll_event ; epoll事件体，事件发生时候你可以得到一个它。其中epoll_event.data.fd可以存储关联的句柄，epoll_event.event是监听标志，常用的有EPOLLIN （有数据[......]
本例子使用异步socket（select方法）实现了ECHO服务器程序。
搞了一个晚上，终于弄好了，出现的问题主要如下：
[cpp]
/*
* main.c[......]