当前位置: 首页 > news >正文

嵌入式第三十八篇——linux系统编程——IPC进程间通信

一、无名管道(Unnamed Pipe)

1. 核心定义

无名管道(简称pipe)是仅支持有亲缘关系进程(如父子、兄弟进程,由同一进程 fork 创建)间通信的临时 IPC 机制,无文件系统实体,仅存在于内存中。

2. 核心特性

  1. 半双工通信:数据只能单向流动,实际编程中通常按单工模式使用(如需双向通信,需创建两个管道)。
  2. 不支持定位操作:管道是流式文件,无法使用lseek(文件 IO)或fseek(标准 IO)进行偏移定位。
  3. 文件操作方式
    • 首选文件 IOopen/read/write/close),无缓冲区,效率更高;
    • 可选标准 IOfgets/fread/fgetc等),但存在缓冲区,需注意数据同步问题。
  4. 阻塞与异常行为(关键):
    场景行为
    读端存在,写端写入超过 64KB写操作阻塞(管道缓冲区默认大小为 64KB)
    写端存在,管道为空时读操作读操作阻塞(等待写端写入数据)
    读端关闭,写端继续写管道管道破裂,写进程被信号终止(SIGPIPE)
    写端关闭,管道无数据时读操作read返回 0(表示通信结束)

3. 编程接口

(1)创建管道函数
#include <unistd.h> int pipe(int pipefd[2]);
  • 功能:创建并打开一个无名管道,返回两个文件描述符。
  • 参数pipefd[0]为管道的读端(固定),pipefd[1]为管道的写端(固定)。
  • 返回值:成功返回 0,失败返回 - 1(并设置errno)。

4. 编程步骤

  1. 创建管道:调用pipe()函数生成读、写端文件描述符。
  2. 创建子进程:调用fork()生成子进程(子进程继承管道描述符)。
  3. 关闭无用端:父子进程分别关闭不需要的读 / 写端(如父进程写、子进程读,则父进程关读端,子进程关写端)。
  4. 读写管道:通过read()/write()进行数据传输。
  5. 关闭管道:通信结束后,关闭剩余的读 / 写端描述符。

二、有名管道(FIFO)

1. 核心定义

有名管道(简称FIFO,First In First Out)是支持任意单机进程(无亲缘关系也可)间通信的 IPC 机制,在文件系统中存在实体文件(有路径和名称),但文件内容仅存于内存中。

2. 核心特性

  • 继承无名管道的所有特性:半双工、不支持定位、阻塞 / 异常行为与无名管道一致。
  • 额外特性
    1. 文件系统可见:通过ls命令可看到 FIFO 文件(文件类型为p)。
    2. open 函数的阻塞特性:若只打开 FIFO 的读端或写端,open()会阻塞,直到另一端也被打开(可通过O_NONBLOCK设置非阻塞模式)。

3. 编程接口

(1)创建有名管道函数
#include <sys/stat.h> int mkfifo(const char *pathname, mode_t mode);
  • 功能:在指定路径下创建一个有名管道文件。
  • 参数
    • pathname:要创建的 FIFO 文件的路径 + 名称(如./myfifo)。
    • mode:FIFO 文件的权限(8 进制数,如0664,最终权限会受umask影响)。
  • 返回值:成功返回 0,失败返回 - 1(并设置errno,如文件已存在时errnoEEXIST)。

4. 编程步骤

  1. 创建 FIFO 文件:调用mkfifo()创建有名管道(若已存在可跳过)。
  2. 打开 FIFO 文件:进程通过open()函数打开 FIFO(指定O_RDONLY/O_WRONLY,可选O_NONBLOCK)。
  3. 读写管道:通过read()/write()进行数据传输(与文件操作一致)。
  4. 关闭管道:通信结束后,调用close()关闭文件描述符。
  5. 卸载 FIFO:通过unlink()rm命令删除文件系统中的 FIFO 实体文件(可选,若后续还需使用可保留)。

三、无名管道与有名管道的核心区别

特性无名管道(Pipe)有名管道(FIFO)
适用进程仅有亲缘关系进程任意单机进程
文件系统实体无(仅内存中存在)有(可见的 FIFO 文件)
创建方式pipe()函数mkfifo()函数
打开方式继承描述符,无需 open需调用open()函数
http://www.cnnetsun.cn/news/178692.html

相关文章:

  • 掌握这4种异常处理模式,轻松应对Open-AutoGLM解密崩溃危机
  • 如何在30分钟内完成Open-AutoGLM加密传输配置?高效运维必看
  • NetSupport Manager 路径遍历漏洞 (CVE-2025-34181) 技术深度解析
  • Electron 实战项目
  • Open-AutoGLM解密异常频发?(企业级容错架构设计实践)
  • 你还在用传统加密?Open-AutoGLM的这4个优势已彻底改写行业规则
  • 企业级城市垃圾分类管理系统管理系统源码|SpringBoot+Vue+MyBatis架构+MySQL数据库【完整版】
  • 为什么你的系统总被Open-AutoGLM误封?一文看懂白名单配置核心要点
  • 【数据安全突围战】:Open-AutoGLM为何成为2024年最值得掌握的加密技术?
  • 使用机器学习简化机构沟通,提升可读性与包容性
  • LangFlow降低AI开发门槛:非技术人员也能构建智能应用
  • LangFlow与LangChain协同工作原理深度剖析
  • 16.2 对齐方法论:FineTune与RAG两大技术路径
  • 16.3 微调技术盘点:产品经理需要了解的核心方法
  • 汇编语言全接触-41.虚拟设备驱动程序初步
  • LangFlow能否实现专利文献摘要提取?科研情报处理
  • 告别熬夜爆肝:百考通AI如何用源码宝库与智能答辩重塑学习体验
  • AI赋能科研:百考通如何让学术起步更高效
  • LangFlow开源生态现状及未来发展方向预测
  • Open-AutoGLM自动化卡顿元凶分析(弹窗阻断深度解析与绕行策略)
  • 揭秘Open-AutoGLM运行时崩溃:为何弹窗错误始终无法捕获?
  • 【Open-AutoGLM加密传输协议配置】:掌握企业级安全通信的5大核心步骤
  • 2026毕设ssm+vue基于企业客户管理系统论文+程序
  • 【紧急故障应对】:Open-AutoGLM上线即超时?立即执行这6项止损操作
  • HoRain云--Java网络编程:BIO、NIO、AIO全解析
  • 基于java+ vue农产投入线上管理系统(源码+数据库+文档)
  • LangFlow能否用于构建智能客服质检系统?会话分析实践
  • Open-AutoGLM加载慢怎么办?3种高效优化策略立即见效
  • LangFlow能否用于构建AI心理咨询师原型?伦理边界探讨
  • Open-AutoGLM权限管理深度优化(90%开发者忽略的弹窗隐患)