进程间消息未被接收的场景分析：发送进程会无限等待吗？

这个场景的结果完全取决于你使用的进程间通信（IPC）机制，不同机制的行为差异很大：

• 若使用阻塞式IPC机制（比如带阻塞属性的System V/POSIX消息队列、无名管道）：

  • 当Process 2暂时无法接收时，Process 1的发送操作会被阻塞，直到Process 2开始接收，或者触发系统设定的超时、队列上限等条件。
  • 如果Process 2始终不接收，且队列未达上限，Process 1会一直处于阻塞状态；若队列已满，部分机制会直接返回发送失败的错误，而非无限等待。

• 若使用非阻塞式/异步IPC机制（比如配置了非阻塞属性的消息队列、UDP套接字、异步RPC框架）：

  • Process 1的发送操作会立即完成，消息会被存入系统缓冲区或中间组件，Process 1可以继续执行后续任务。
  • 如果Process 2始终不接收，消息要么一直保留在缓冲区直到被系统回收或手动清理（比如消息队列），要么直接被丢弃（比如UDP），不会影响Process 1的正常运行。

• 若使用信号类通信机制：

  • Process 1发送信号后会立即返回，不会等待Process 2处理。如果Process 2未注册对应信号的处理函数，信号会被系统忽略，相当于消息直接“丢失”。

简单总结：核心区别在于发送操作是否阻塞——阻塞式机制会让Process 1等待接收方，非阻塞式则发送后就独立运行，消息的最终命运由具体IPC规则决定。

内容的提问来源于stack exchange，提问作者Emma van de Vreugde