今天执行`strace`的时候发现，不管哪个进程最后都会调用`exit_group`,就打算总结一下进程退出相关的系统调用。
，查阅资料后发现有以下。

![image.png](/static/img/402013280d37a8d687eb5968a11fb483.image.webp)
**1. `exit()`：**
- `exit()` 是标准 C 库中的函数，用于终止当前进程。
- 函数原型：`void exit(int status);`
- 调用 `exit()` 函数将终止当前进程，并将退出状态 `status` 返回给父进程。
- `exit()` 函数将执行一系列清理操作，包括关闭文件描述符、刷新缓冲区以及执行通过 `atexit()` 注册的终止处理程序。
- 可以使用 `EXIT_SUCCESS` 和 `EXIT_FAILURE` 宏来表示进程的成功或失败状态。



**2. `_exit()`：**
- `_exit()` 是一个系统调用，用于立即终止当前进程，不执行清理操作。
- 函数原型：`void _exit(int status);`
- 调用 `_exit()` 函数将立即终止当前进程，并将退出状态 `status` 返回给父进程。
- `_exit()` 不会执行清理操作，包括不会关闭文件描述符、不会刷新缓冲区，也不会执行终止处理程序。

**3. `atexit()`：**
- `atexit()` 函数用于注册在进程终止时自动执行的终止处理程序。
- 函数原型：`int atexit(void (*function)(void));`
- 通过调用 `atexit()` 函数并传递一个函数指针，可以注册一个终止处理程序。
- 注册的终止处理程序将在进程正常终止时被调用，执行一些清理操作。
- 可以多次调用 `atexit()` 来注册多个终止处理程序，它们将按照注册的相反顺序执行。

**4. `exit_group()`：**
   
- `exit_group()` 是 Linux 特定的系统调用，用于终止整个进程组中的所有进程，包括当前进程。
- 函数原型：`void exit_group(int status);`
- 调用 `exit_group()` 将立即终止当前进程组中的所有进程，包括当前进程。
- `exit_group()` 不执行清理操作，也不返回到调用进程，因为它会终止整个进程组。

这些 API 提供了不同的方式来控制进程的退出和清理操作。

接下来演示一下网上找到的的示例程序

1. 示例程序：使用 `exit()` 终止进程

```c
#include <stdio.h>
#include <stdlib.h>

int main() {
    printf("This is the main process.\n");
    
    // 调用 exit() 终止当前进程
    exit(EXIT_SUCCESS);
    
    // 下面的代码不会被执行
    printf("This line will not be printed.\n");
    
    return 0;
}
```

当程序执行到 `exit()` 时，当前进程将被终止。因此，`printf()` 函数后面的代码将不会被执行。

1. 示例程序：使用 `_exit()` 终止进程

```c
#include <stdio.h>
#include <unistd.h>

int main() {
    printf("This is the main process.\n");
    
    // 调用 _exit() 终止当前进程
    _exit(EXIT_SUCCESS);
    
    // 下面的代码不会被执行
    printf("This line will not be printed.\n");
    
    return 0;
}
```

当程序执行到 `_exit()` 时，当前进程将被立即终止。与 `exit()` 不同，`_exit()` 不执行清理操作，直接退出。

1. 示例程序：使用 `atexit()` 注册终止处理程序

```c
#include <stdio.h>
#include <stdlib.h>

void cleanup() {
    printf("Executing cleanup...\n");
    // 执行一些清理操作
}

int main() {
    printf("This is the main process.\n");
    
    // 注册终止处理程序
    atexit(cleanup);
    
    // 调用 exit() 终止当前进程
    exit(EXIT_SUCCESS);
    
    // 下面的代码不会被执行
    printf("This line will not be printed.\n");
    
    return 0;
}
```

`cleanup()` 函数作为终止处理程序被注册。当进程正常终止时，注册的终止处理程序将被调用，执行一些清理操作。

1. 示例程序：使用 `exit_group()` 终止进程组中的所有进程

```c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>

int main() {
    printf("This is the main process. PID: %d\n", getpid());
    
    // 创建一个子进程
    pid_t child_pid = fork();

    if (child_pid == 0) {
        // 子进程
        printf("This is the child process. PID: %d\n", getpid());
        
        // 子进程调用 exit_group() 终止整个进程组
        exit_group(EXIT_SUCCESS);
    } else if (child_pid > 0) {
        // 父进程
        printf("This is the parent process. PID: %d\n", getpid());
        
        // 等待子进程终止
        int status;
        wait(&status);
        
        if (WIFEXITED(status)) {
            printf("Child process terminated with exit status: %d\n", WEXITSTATUS(status));
        }
    } else {
        // fork() 失败
        perror("fork");
        exit(EXIT_FAILURE);
    }
    
    // 下面的代码不会被执行
    printf("This line will not be printed.\n");
    
    return 0;
}
```

在这个示例中，主进程创建了一个子进程，并等待子进程终止。子进程调用了 `exit_group()` 终止整个进程组。当子进程终止后，父进程会检查子进程的退出状态并打印出来。

进程组是进程的集合，通常是由父进程创建，父进程创建子进程并将其加入到自己这个进程组，进程组的PGID就等于父进程自己的PID,子进程初始的PGID也等于父进程的PID,除非子进程创建会话成为另一个会话的领导者，子进程的PGID会变成自己的PID,还有通过`setpgid`手动加入到其他进程组。

所以，`exit_group`会杀死和这个程序有关的所有进程。s

进程退出相关system call

```go
go env -w GOPROXY=https://goproxy.io,direct

```

go更换七牛云镜像源

```go
package main

import (
	"archive/zip"
	"fmt"
	"github.com/gin-gonic/gin"
	"io"
	"net/http"
	"os"
	"path/filepath"
)



func zipDirectory(directoryPath string, zipFilePath string) error {
	zipFile, err := os.Create(zipFilePath)
	if err != nil {
		return err
	}
	defer zipFile.Close()

	zipWriter := zip.NewWriter(zipFile)
	defer zipWriter.Close()

	err = filepath.Walk(directoryPath, func(filePath string, fileInfo os.FileInfo, err error) error {
		if err != nil {
			return err
		}

		if !fileInfo.Mode().IsRegular() {
			return nil
		}

		relativePath, err := filepath.Rel(directoryPath, filePath)
		if err != nil {
			return err
		}

		file, err := os.Open(filePath)
		if err != nil {
			return err
		}
		defer file.Close()

		zipEntry, err := zipWriter.Create(filepath.ToSlash(relativePath))
		if err != nil {
			return err
		}

		_, err = io.Copy(zipEntry, file)
		return err
	})

	return err
}

func handleDirectoryDownload(c *gin.Context) {
	// 要压缩的目录路径
	Name := c.Param("filename")
	directoryPath := fmt.Sprintf("%s/%s", "static", Name)

	// 创建临时的 ZIP 文件
	zipFilePath := fmt.Sprintf("%s.zip", Name)
	fmt.Println(zipFilePath)
	err := zipDirectory(directoryPath, zipFilePath)
	if err != nil {
		c.String(500, "创建错误！")
		return
	}
	defer os.Remove(zipFilePath)
	val := fmt.Sprintf("attachment; filename=%s.zip", Name)
	// 设置响应头，指定文件名和 MIME 类型
	//c.Header("Content-Disposition", "attachment; filename=download.zip")
	c.Header("Content-Disposition", val)
	c.Header("Content-Type", "application/zip")

	// 将 ZIP 文件内容写入响应体
	http.ServeFile(c.Writer, c.Request, zipFilePath)
}

func main() {
	r := gin.Default()
	r.GET("/download/:filename", handleDirectoryDownload)

	r.Run(":8080")
}

```

go实现文件服务器

```cpp
#include <iostream>
#include <string>
#include <cmath>
#include <algorithm>



std::string to_string(int val){
    std::string result;
    bool flag=false;
    if(!val){
        return "0";
    }
    if(val<0){
        flag=true;
        val=-val;
    }
    
    while (val>0)
    {
        /* code */
        result += '0' + val % 10;
        val/=10;
    }

    if(flag){
        result+="-";
    }

    std::reverse(result.begin(),result.end());
    return result;
    
}

std::string to_string(double val){
    std::string result;
    bool flag;

    if(!val){
        return "0.0";
    }

    if(val<0){
        flag=true;
        val=-val;
    }

    auto intx = static_cast<int>(val);
    double fx= val-intx;

    result=to_string(intx);

    if(fx>0){
        result+=".";
        while(fx>0.000001){
            fx*=10;
            int d=static_cast<int> (fx);
            result+='0'+d;
            fx-=d;
        }
    }
    if(flag){
        result.insert(result.begin(),'-');
    }
    return result;
}
int main(){
    auto i=520;
    auto x=3.1415826;
    std::cout<<to_string(x)<<'\n';
}
```

cpp实现数字转字符串算法

## OCI
OCI（Open Container Initiative）是一个开放的、供应用容器化的技术标准化组织。它的目标是推动容器相关技术的标准化和互操作性，为容器生态系统提供一个统一的基础。

OCI 由多家技术公司和社区组成，包括 Docker、CoreOS、Red Hat、Google、Microsoft 等。它成立于2015年，并得到了业界广泛的支持和参与。

OCI 的工作重点主要包括两个方面：



1. **OCI Runtime Specification（OCI-R）**: 定义了容器运行时的规范，包括容器的生命周期管理、进程隔离、文件系统、网络和资源配置等方面的标准。这个规范由 OCI 组织内的运行时工作组制定，旨在确保不同容器运行时之间的互操作性和可移植性。

2. **OCI Image Specification（OCI-I）**: 定义了容器镜像的规范，包括镜像格式、镜像层次结构、元数据和签名等方面的标准。这个规范由 OCI 组织内的镜像工作组制定，旨在确保容器镜像的可移植性和互操作性。

OCI 的目标是创建一个开放的标准化平台，使得不同容器运行时和工具能够无缝地协同工作，提高容器技术的互操作性和可移植性。通过采用 OCI 规范，用户可以更灵活地选择容器运行时和工具，并将容器镜像在不同的平台和环境中进行部署和交付。

OCI 的规范和项目都是开放的，并得到了广泛的社区支持。


## CRI
CRI（Container Runtime Interface）是一个 Kubernetes 项目中的标准化接口，用于与容器运行时进行交互。它定义了容器运行时与 Kubernetes kubelet 组件之间的通信协议和接口规范。

在 Kubernetes 集群中，kubelet 是负责管理和运行容器的主要组件。而容器运行时负责实际创建和管理容器的过程，如 runc、containerd 等。CRI 的目的是将 kubelet 与容器运行时解耦，使其能够与不同的容器运行时进行交互，实现更高的可插拔性和互操作性。

CRI 定义了一组 gRPC API，包括运行容器、停止容器、获取容器状态、拉取和推送镜像等操作。这些 API 提供了与容器运行时进行交互的统一方式，使得 Kubernetes 能够与任何符合 CRI 规范的容器运行时进行通信。

采用 CRI，Kubernetes 可以与不同的容器运行时进行集成，而不需要对 kubelet 进行修改。这使得用户可以选择适合其需求的容器运行时，并且能够无缝地切换或升级容器运行时，而不对 Kubernetes 集群的其他部分产生影响。

CRI 是 Kubernetes 中定义容器运行时与 kubelet 之间通信接口的规范，它提供了一致的方法来管理和操作容器，以实现 Kubernetes 与不同容器运行时的集成和互操作性。



## CRI-O
CRI-O 是一个针对 Kubernetes 的容器运行时实现，它遵循 Open Container Initiative (OCI) 规范，并提供与 Kubernetes Container Runtime Interface (CRI) 进行交互的功能。

CRI-O 的设计目标是将 Kubernetes kubelet 与容器运行时解耦，以实现更高的可插拔性和互操作性。它通过实现 CRI 接口规范，使得 Kubernetes 能够与符合 CRI 规范的容器运行时进行通信，而不需要直接依赖特定的容器运行时实现。

CRI-O 基于 OCI 规范，使用标准的 OCI 容器和镜像格式，如 OCI Runtime Specification 和 OCI Image Specification。它支持使用标准容器运行时（如 runc）来创建和管理容器，并提供了一组 gRPC API，包括运行容器、停止容器、获取容器状态、拉取和推送镜像等操作。

CRI-O 优点：

- **轻量和高度可定制**：CRI-O 针对 Kubernetes 运行时的需求进行了优化，避免了不必要的复杂性和额外的组件。
- **符合标准**：CRI-O 遵循 OCI 规范和 CRI 接口规范，与其他符合这些标准的工具和容器运行时实现具有良好的互操作性。
- **安全和稳定**：CRI-O 将安全性和稳定性放在首位，采用最佳实践来保护容器和集群的安全性。

CRI-O 是一个符合 CRI 接口规范的容器运行时实现，它为 Kubernetes 提供了与容器的交互功能，并遵循 OCI 标准，以提供轻量、可定制、安全和稳定的容器运行环境。


## Containerd
containerd 是一个开源的容器运行时，它作为 Docker 引擎的核心组件之一，负责管理容器的生命周期和运行时环境。2017年docker把containerd开源出来，现已成为一个独立项目，是当前k8s默认使用的容器运行时。

containerd 的设计目标是提供一个可靠、高效、可扩展的容器运行时，以满足不同的应用场景和需求。它专注于容器的基本功能，如容器的创建、启动、停止和销毁等操作，以及容器和镜像的管理。

作为一个独立的容器运行时，containerd 提供了一组功能丰富的 API 接口，使开发者能够直接与其交互，管理容器和镜像。它还支持多种容器格式和容器镜像格式，如 OCI（Open Container Initiative）标准定义的容器和镜像规范。

containerd 的架构设计具有模块化和可插拔的特点，使得它可以与不同的容器生态系统和工具进行集成。它提供了插件机制，可以扩展其功能，如网络、存储和安全等方面。这使得 containerd 可以作为容器运行时的核心组件，并与其他相关工具和服务进行集成，以构建完整的容器解决方案。

除了作为 Docker 引擎的核心组件之一，containerd 也被广泛应用于其他容器平台和工具中，如 Kubernetes 和 CRI（Container Runtime Interface）等。它的稳定性、可靠性和高性能使得它成为容器生态系统中重要的基础设施组件之一。


## Runc
runc 是一个开源的命令行工具，用于运行和管理符合 OCI（Open Container Initiative）规范的容器。它是一个基于标准的容器运行时工具，实现了 OCI Runtime Specification 中定义的容器运行时接口。

runc 是 OCI 标准的参考实现之一，由 OCI 组织开发和维护。它使用 Linux 的 cgroups、命名空间（namespaces）和联合文件系统（union filesystem）等功能来创建和管理容器。runc 提供了一组命令行工具，可以用于创建、启动、停止、删除和查询容器的状态等操作。

runc 有以下特征：

- **符合标准**：runc 遵循 OCI Runtime Specification，确保与其他符合该规范的工具和容器运行时实现具有良好的互操作性。
- **轻量和可定制**：runc 提供基本的容器运行时功能，没有额外的复杂性，可以根据需要进行定制和扩展。
- **安全和稳定**：runc 采用安全最佳实践，并注重容器和宿主机的隔离性，提供安全可靠的容器运行环境。
- **跨平台支持**：runc 不仅在 Linux 上可用，还可以在其他操作系统平台上运行容器，如 Windows 和 macOS。

runc 可以作为容器运行时的基础组件，被其他容器管理器或容器编排工具使用。它提供了一种通用的方式来创建和管理容器，使得不同的容器工具和平台可以使用相同的容器格式和运行时接口。

虽然 runc 是一个强大且广泛使用的容器运行时工具，但它本身并不是一个完整的容器管理器或编排工具，而是专注于容器的低级运行时操作。