NetBSD 进程间通讯系统分析

核心提示： 我们又进入了一个与 pipe_read() 相似的循环. (XXX. NODIRECT) 接下来的处理过程也是相似的, 注意 space 的计算, 我们倾向于一次性把数据写入, 如果不行, 我们宁愿先等待. 管道关闭pipe_close() 只需应付一下文件接口, 将 f_data 清空,

我们又进入了一个与 pipe_read() 相似的循环. (XXX. NODIRECT) 接下来的处理过程也是相似的, 注意 space 的计算, 我们倾向于一次性把数据写入, 如果不行, 我们宁愿先等待.

管道关闭

pipe_close() 只需应付一下文件接口, 将 f_data 清空, 真正的 pipe 关闭工作由 pipeclose() 完成. 在这里, 我们主要要修改对端状态, 告诉它我们要死了, pipe 结束了, 把对端指向自己的 pipe_peer 域清空. 然后对因读或写等待的对端, 唤醒之, 让它处理这个事件. 接着, 我们返还所有资源: 缓冲区(如果是读端口), pipe 结构, 这个端口的生命就结束了.

BSD 进程间通讯: socket

请参考 BsdSrcSocket

SystemV IPC

SystemV IPC 是由商业发行 SystemV UNIX 带来的通信机制. 它包括消息, 共享存储区, 信号量, 实现了良好的本地进程通信接口. 在 NetBSD 中实现的代码在 kern/sysv_*.

对象标识

作为进程间通讯单位并允许多个进程 (而非 pipe 的两个进程点对点) 通讯, 其通讯单位显然是系统的且全局的. 三种通信机制的对象都有相同的标识方法: 每种机制都包含一个表, 其中的表项描述该机制的所有实例; 每个表项都有一个用户选定的 key, 各个进程可以通过 key 获取通信对象实例, 从而互相通信. 每个通信对象实例又对应一个全局唯一的标识符, 以进行真正的通信.

考虑这个全局标识符就是对象实例再表中的位置, 我们将面临一种情况, 某个程序使用一个 id 做通讯, 可是这个 id 所对应的通信实例可能已被撤消, 这个位置又换上了另一个通信实体, 而这个程序对此一无所知, 继续操作, 这会造成灾难性后果. 我们的解决方法是加上一个 _seq 域, 每次申请一个实例, 就将其 _seq 域加 1, 我们返回的标识符为 _seq * 65536 + 实例在表中的位置, 这样就不会产生这种混乱了.