?在 init进程启动的第二阶段，会调用signal_handler_init()，装载子进程信号处理器，该函数定义于system/core/init/signal_handler.cpp中。
void signal_handler_init() {
// Create a signalling mechanism for SIGCHLD.
int s[2];
//利用socketpair创建出已经连接的两个socket，分别作为信号的读、写端
if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK | SOCK_CLOEXEC, 0, s) == -1) {
PLOG(ERROR) << "socketpair failed";
exit(1);
}
signal_write_fd = s[0];
signal_read_fd = s[1];
// Write to signal_write_fd if we catch SIGCHLD.
struct sigaction act;
memset(&act, 0, sizeof(act));
//信号处理器对应的执行函数为SIGCHLD_handler
//被存在sigaction结构体中，负责处理SIGCHLD消息
act.sa_handler = SIGCHLD_handler;
act.sa_flags = SA_NOCLDSTOP;
//调用信号安装函数sigaction，将监听的信号及对应的信号处理器注册到内核中
sigaction(SIGCHLD, &act, 0);
//用于终止出现问题的子进程，详细代码于后文分析。
ServiceManager::GetInstance().ReapAnyOutstandingChildren();
//注册epoll处理函数handle_signal
register_epoll_handler(signal_read_fd, handle_signal);
}
其中，SIGCHLD_handler函数会在init收到子进程的SIGCHILD信号时被调用，定义为
static void SIGCHLD_handler(int) {
if (TEMP_FAILURE_RETRY(write(signal_write_fd, "1", 1)) == -1) {
PLOG(ERROR) << "write(signal_write_fd) failed";
}
}
?handle_signal函数会在epoll到signal_read_fd中有数据时被调用，定义于system/core/init/signal_handler.cpp中：
static void handle_signal() {
// Clear outstanding requests.
char buf[32];
read(signal_read_fd, buf, sizeof(buf));
ServiceManager::GetInstance().ReapAnyOutstandingChildren();
}
至此，结合上文我们知道：
当init进程调用signal_handler_init后，一旦收到子进程终止带来的SIGCHLD消息后，
将利用信号处理者SIGCHLD_handler向signal_write_fd写入信息；
由于绑定的关系，epoll句柄将监听到signal_read_fd收到消息，
于是将调用handle_signal进行处理。
整个过程可以用以下图片来描述
?在ServiceManager::GetInstance().ReapAnyOutstandingChildren();函数中，会调用waitpid(-1, &status, WNOHANG)来获取退出的子进程id以便后续处理。
在经过内核的学习后，我们知道，退出的子进程自身是不能释放自己的系统堆栈和task_struct结构体的。一方面是因为task_struct结构体中有一些统计信息，需要归入父进程。另外一方面在发生中断和系统调用时，会使用当前进程的系统堆栈，如果此时释放了，就没有一个“当前进程”了，这样就造成了”空洞“。因此子进程通过发送SIGCHILD信号，通知父进程来料理后事。而父进程则可以通过wait4系统调用来等待子进程的退出，并进行相应的回收工作。
当进程从系统调用中断或异常返回时，会调用do_signal来处理信号，如果父进程定义了SIGCHILD的处理函数为SIG_IGN，则会调用sys_wait4(-1, NULL, WNOHANG ,NULL)来检查是否有TASK_ZOMBIE状态的子进程，如果存在则对其进行回收以及统计信息的处理，从此，退出的子进程就再也不存在了。
那么既然内核原生完全可以处理子进程退出，不至于造成僵尸进程，为什么android还要重新定义SIGCHILD并且手动调用waitpid呢？答案其实很简单，内核对于子进程退出的处理主要有两部分：
1.子进程释放用户空间的内存以及文件fd信号量等资源
2.父进程释放子进程的系统堆栈和进程控制块
这两项处理都能保证子进程正常退出，但是android对于service还有其他一些管理，比如根据initrc文件的定义，退出后的service是否需要重启，重启时是否有onestart命令需要执行等等是原生Linux没有做的。
还有个疑问需要实验，如果父进程重新定义了SIGCHILD的处理函数，即struct_task结构体中对应的sig_handler[]函数指针不为SIG_IGN，那么是否一定需要手动调用wait4呢？
?
