多进程服务器端#

10.1 进程概念及应用#

之前实现的迭代服务器端每次只能服务一个客户端。当前面的客户端尚未结束通信时，后续请求只能留在等待队列中。网络通信的等待时间通常大于 $CPU$ 运算时间，因此让多个客户端同时获得服务，也能更有效地利用系统资源。

常见的并发服务器端有以下几种实现方式：

通过创建多个进程提供服务。
通过 $I/O$ 复用统一管理多个 $I/O$ 对象。
通过创建多个线程提供服务。

本章主要介绍 $Linux$ 下的多进程方式。 $Windows$ 不支持同样的 $fork$ 进程模型，因此没有对应的平台实现。

理解进程#

进程（ $Process$ ）简单来说就是“占用内存空间且正在运行的程序”。保存在硬盘上但尚未运行的只是程序；当它被加载到内存并开始执行时，才成为进程。

操作系统会为每个进程分配唯一的进程 $ID$ ，即 $PID$ 。在 $Linux$ 中可以通过 $ps$ 命令查看正在运行的进程及其 $PID$ 。

通过fork创建进程#

$fork$ 用于创建当前进程的副本：

1
#include <unistd.h>
2

3
pid_t fork(void);
4
//成功时在父进程中返回子进程ID，
5
//在子进程中返回0，失败时返回-1。

调用 $fork$ 后，父子进程都会从函数返回位置继续执行，所以必须根据返回值区分两条执行流：

1
pid_t pid = fork();
2

3
if (pid == 0)
4
{
5
    /* 子进程执行区域 */
6
}
7
else
8
{
9
    /* 父进程执行区域，pid是子进程ID */
10
}

$fork$ 会复制父进程当时的内存状态，但复制完成后父子进程拥有彼此独立的内存空间。一方修改全局变量或局部变量，不会直接影响另一方。

10.2 进程和僵尸进程#

子进程执行完 $main$ 的 $return$ ，或者调用 $exit$ 后，会把终止状态交给操作系统。操作系统不会立即删除该进程，而是保留这些信息，等待父进程读取。在终止状态尚未被回收期间，子进程就处于僵尸进程（ $Zombie\ Process$ ）状态。

僵尸进程已经不再执行业务代码，但仍会占用进程表等系统资源。因此，父进程需要主动获取子进程的终止状态。

利用wait销毁僵尸进程#

1
#include <sys/wait.h>
2

3
pid_t wait(int *statloc);
4
//成功时返回终止的子进程ID，失败时返回-1。

$wait$ 会把某个已终止子进程的状态写入 $statloc$ 指向的内存，同时完成该子进程的回收。可以通过宏拆分其中的信息：

1
int status;
2
wait(&status);
3

4
if (WIFEXITED(status))
5
    printf("Child return: %d\n", WEXITSTATUS(status));

$WIFEXITED$ 用于判断子进程是否正常终止， $WEXITSTATUS$ 用于取出返回值。若尚无子进程结束， $wait$ 会阻塞等待，因此需谨慎调用。

利用waitpid避免阻塞#

1
#include <sys/wait.h>
2

3
pid_t waitpid(pid_t pid, int *statloc, int options);
4
//成功时返回终止的子进程ID，
5
//使用WNOHANG且暂无子进程结束时返回0。

$pid$ 为 $-1$ 时表示等待任意子进程。第三个参数传入 $WNOHANG$ 后，即使尚无子进程终止也不会阻塞，而是直接返回 $0$ 。

10.3 信号处理#

父进程通常还要继续受理连接，不能不断调用 $waitpid$ 轮询子进程是否终止。子进程结束时，操作系统会向父进程发送 $SIGCHLD$ 信号；父进程可以注册对应的处理函数，只在信号到来时回收子进程。

signal函数#

1
#include <signal.h>
2

3
void (*signal(int signo, void (*func)(int)))(int);

$signo$ 表示需要关注的信号， $func$ 是信号发生时由操作系统调用的处理函数。常见信号包括：

信号	含义
SIGCHLD	子进程终止
SIGALRM	$alarm$ 设置的时间到达
SIGINT	用户输入 $Ctrl+C$

例如，子进程终止时调用 $read\_childproc$ ：

1
signal(SIGCHLD, read_childproc);

书中还通过 $alarm$ 演示了定时信号：

1
#include <unistd.h>
2

3
unsigned int alarm(unsigned int seconds);

调用后经过指定秒数会产生 $SIGALRM$ 。信号到来时，还会唤醒因 $sleep$ 等函数处于阻塞状态的进程。

使用sigaction注册信号#

$signal$ 在不同 $UNIX$ 系统中可能存在行为差异，实际程序中更常使用 $sigaction$ ：

1
#include <signal.h>
2

3
int sigaction(int signo, const struct sigaction *act,
4
              struct sigaction *oldact);
5
//成功时返回0，失败时返回-1。

用于回收子进程的核心结构如下：

1
void read_childproc(int sig)
2
{
3
    int status;
4
    while (waitpid(-1, &status, WNOHANG) > 0);
5
}
6

7
struct sigaction act;
8
act.sa_handler = read_childproc;
9
sigemptyset(&act.sa_mask);
10
act.sa_flags = 0;
11
sigaction(SIGCHLD, &act, 0);

当 $SIGCHLD$ 产生时，处理函数通过非阻塞的 $waitpid$ 取走子进程终止状态，从而避免僵尸进程残留。

10.4 基于多任务的并发服务器#

多进程回声服务器端的基本逻辑是：父进程专门通过 $accept$ 受理连接，每当得到一个客户端套接字后调用 $fork$ ，由新建子进程为该客户端提供服务。

父进程负责反复受理连接，子进程则独立处理已连接客户端。核心代码可以简化为：

1
while (1)
2
{
3
    clnt_sock = accept(serv_sock,
4
                       (struct sockaddr *)&clnt_adr, &adr_sz);
5
    if (clnt_sock == -1)
6
        continue;
7

8
    pid = fork();
9
    if (pid == 0)
10
    {
11
        close(serv_sock);
12
        while ((str_len = read(clnt_sock, buf, BUF_SIZE)) != 0)
13
            write(clnt_sock, buf, str_len);
14

15
        close(clnt_sock);
16
        return 0;
17
    }
18
    else
19
    {
20
        close(clnt_sock);
21
    }
22
}

fork与套接字文件描述符#

$fork$ 复制的是套接字文件描述符，而不是在操作系统中创建一个新套接字。父子进程中的描述符会指向同一套接字对象。

如果父子进程都保留所有描述符，即使其中一方调用 $close$ ，套接字也不会立即被销毁。只有指向该套接字的相关描述符全部关闭后，操作系统才会真正销毁它。

所以调用 $fork$ 后应立即整理无关描述符：

子进程不负责接受新连接，应关闭 $serv\_sock$ 。
父进程不负责当前客户端的数据交换，应关闭自己持有的 $clnt\_sock$ 副本。

父进程继续调用 $accept$ ，各子进程独立处理已连接客户端，便实现了同时向多个客户端提供服务。

10.5 分割TCP的I/O程序#

之前的回声客户端按照“发送一次，等待回声，再发送下一次”的顺序工作。利用 $fork$ 可以把收发逻辑拆分到两个进程中：父进程只负责接收，子进程只负责发送。

这样一方面可以简化代码，另一方面使数据发送不再必须等待前一次接收完成。如图所示， $I/O$ 分割后客户端可以连续发送数据，对频繁交换数据的程序更有意义。

客户端中的分工可以简化为：

1
pid = fork();
2

3
if (pid == 0)
4
    write_routine(sock, buf);  //子进程只发送
5
else
6
    read_routine(sock, buf);   //父进程只接收

发送进程遇到退出输入时，需要对输出流执行半关闭：

1
if (!strcmp(buf, "q\n") || !strcmp(buf, "Q\n"))
2
{
3
    shutdown(sock, SHUT_WR);
4
    return;
5
}

由于 $fork$ 后父子进程都持有指向同一套接字的描述符，只在发送进程中调用 $close$ 并不能立即向服务器传递 $EOF$ 。调用 $shutdown(sock, SHUT\_WR)$ 可明确关闭套接字的输出流，同时让另一进程继续接收服务器剩余的数据。

Mkrari的个人博客