一个“永不结束”的服务端进程

以前只知道一个端口用同一个协议只能有一个进程来监听；fork会继承文件描述符。
遂有疑惑，若先listen，再fork，后accept，哪个进程得到客户端的链接？

通过实验，得出结论：
fork之后两个进程会抢占accept的机会，没抢到的进程会阻塞，等待有权accept的进程死掉，然后去accept。

过程：
当启动进程后，用netstat命令查看到在监听的pid，只能看到一个pid在那监听；
然后，用浏览器去链接这个端口，这时在监听的进程接收消息，然后sleep，再用netstat查看，在监听端口的pid没变；
sleep时间到，进程结束，这时用nentstat查看，pid变成了另一个

应用：
用于多进程提供服务是不行的，但是，可以用于防服务进程挂掉，一旦主服务进程挂掉，备份马上就会顶上去，只要备份进程再去fork一个子进程作为备份进程，就可以形成一个“永不结束”的进程。一来避免了服务器死掉再人工启动的反应时间，二来，不必等待监听的进程挂掉后释放端口的时间。