>

引言:上篇文章讲到同步阻塞迭代式的进程方式,这篇文章讲述一下关于处理单进程阻塞于系统调用的情况。使用方式是多进程的方式,可以减少很大一部分的因为进程阻塞所带来的服务器无法响应问题。

基本思想是这样,如上篇文章所述,在单进程阻塞在read() 系统调用的时候,会导致服务器无法响应其他的连接请求,那么我们可以通过在服务器fork() 出很多子进程来处理业务,而主进程负责 accept() 其他的客户连接。

主体框架是这样:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
for(;;){
fd = accept(...);
ret = fork() ;
switch(ret) {
case -1 :
do_err_handler();
break;
case 0 : // child process
do_handler_fd(fd);
break ;
default : // parent process
continue ;
}
}

总体来说,符合上述所说的,主进程负责 accept() 连接,子进程处理连接。
当然,在 do_handler_fd(fd) 中,可以关闭监听套接口等,只负责处理连接套接口。处理过程也是和上一章所说的一样。

1
2
3
read(fd, buf, n);
dosomething(buf);
write(fd, buf, n);

在父进程中需要设置信号处理函数,用来处理子进程退出时候产生的 SIG_CHLD 型号,信号处理函数中调用 wait() 。避免产生僵尸进程、

我们来比较一下这个模型和前一个同步阻塞迭代式:

(1)并发量:这里的服务器主进程不再阻塞于 read() 或者 write() 系统调用,而是通过子进程完成业务处理。阻塞也只是阻塞在子进程中。那么可以减轻服务器主进程的相应时间要求。并发量大大加强,但是会受到操作系统的限制。
(2)代码复杂度:越到后面的代码复杂度肯定越高,开发难度也会慢慢加强。
(3)稳定性:服务器的稳定性现在两个版本还没有体现出来。不过如果没有处理好进程之间的协作和并发控制等第二个版本还是会比第一个版本稍微显得不稳定。

多进程还有另一种方式 Pre-fork 方式,也就是进程池方式,这里没有做过多的介绍,以后会加上这部分内容。

总结:
说一下多进程并发式的服务器端模型的好处就是,主进程不用阻塞在IO系统调用中,而专注于负责处理连接请求。但是,进程本身的开销是很大的,频繁的创建进程会消耗很多务器端的资源。所以,还有其他的处理方式,那就是线程模型。既然创建多进程消耗系统资源,我们可以采取采用线程的方式来达到目的。这就是下一篇文章要谈论的:多线程方式(会有一个线程池的实例)