linux进程间文件描述符传递,LINUX进程间传递描述符.docx

LINUX进程间传递描述符

进程间传递描述符每个进程都拥有自己独立的进程空间，这使得描述符在进程之间的传递变得有点复杂，这个属于高级进程间通信的内容，下面就来说说。顺便把 Linux 和 Windows 平台都讲讲。Linux 下的描述符传递Linux 系统系下，子进程会自动继承父进程已打开的描述符，实际应用中，可能父进程需要向子进程传递“后打开的描述符”，或者子进程需要向父进程传递；或者两个进程可能是无关的，显然这需要一套传递机制。简单的说，首先需要在这两个进程之间建立一个 Unix 域套接字接口作为消息传递的通道( Linux 系统上使用 socketpair 函数可以很方面便的建立起传递通道)，然后发送进程调用 sendmsg 向通道发送一个特殊的消息，内核将对这个消息做特殊处理，从而将打开的描述符传递到接收进程。然后接收方调用 recvmsg 从通道接收消息，从而得到打开的描述符。然而实际操作起来并不像看起来那样单纯。先来看几个注意点：1 需要注意的是传递描述符并不是传递一个 int 型的描述符编号，而是在接收进程中创建一个新的描述符，并且在内核的文件表中，它与发送进程发送的描述符指向相同的项。2 在进程之间可以传递任意类型的描述符，比如可以是 pipe ， open ， mkfifo 或 socket ， accept 等函数返回的描述符，而不限于套接字。3 一个描述符在传递过程中(从调用 sendmsg 发送到调用 recvmsg 接收)，内核会将其标记为“在飞行中”( in flight )。在这段时间内，即使发送方试图关闭该描述符，内核仍会为接收进程保持打开状态。发送描述符会使其引用计数加 1 。4 描述符是通过辅助数据发送的(结构体 msghdr 的 msg_control 成员)，在发送和接收描述符时，总是发送至少 1 个字节的数据，即使这个数据没有任何实际意义。否则当接收返回 0 时，接收方将不能区分这意味着“没有数据”(但辅助数据可能有套接字)还是“文件结束符”。5 具体实现时， msghdr 的 msg_control 缓冲区必须与 cmghdr 结构对齐，可以看到后面代码的实现使用了一个 union 结构来保证这一点。msghdr 和 cmsghdr 结构体上面说过，描述符是通过结构体 msghdr 的 msg_control 成员送的，因此在继续向下进行之前，有必要了解一下 msghdr 和 cmsghdr 结构体，先来看看 msghdr 。struct msghdr { void *msg_name; socklen_t msg_namelen; struct iovec *msg_iov; size_t msg_iovlen; void *msg_control; size_t msg_controllen; int msg_flags; }; 结构成员可以分为下面的四组，这样看起来就清晰多了：1 套接口地址成员 msg_name 与 msg_namelen ；只有当通道是数据报套接口时才需要； msg_name 指向要发送或是接收信息的套接口地址。 msg_namelen 指明了这个套接口地址的长度。msg_name 在调用 recvmsg 时指向接收地址，在调用 sendmsg 时指向目的地址。注意， msg_name 定义为一个 (void *) 数据类型，因此并不需要将套接口地址显示转换为 (struct sockaddr *) 。2 I/O 向量引用 msg_iov 与 msg_iovlen 它是实际的数据缓冲区，从下面的代码能看到，我们的 1 个字节就交给了它；这个 msg_iovlen 是 msg_iov 的个数，不是什么长度。msg_iov 成员指向一个 struct iovec 数组， iovc 结构体在 sys/uio.h 头文件定义，它没有什么特别的。struct iovec { ptr_t iov_base; /* Starting address */ size_t iov_len; /* Length in bytes */};有了 iovec ，就可以使用 readv 和 writev 函数在一次函数调用中读取或是写入多个缓冲区，显然比多次 read ， write 更有效率。 readv 和 writev 的函数原型如下：#include int readv(int fd, const struct iovec *vector, int count);int writev(int fd, const st