select()结合pipe()与fork()使用的异常行为原理咨询

现象底层原理 #

两个核心前置规则 #

• 管道的生命周期由内核维护的读写端引用计数决定：fork会复制进程打开的文件描述符，每个持有关联管道端的进程退出或主动关闭fd时，对应引用计数减1，只有写端的引用计数归0时，管道才会进入EOF状态。
• POSIX标准规定，select检测管道读端可读的条件包含两种情况：
  1. 管道内有未读取的数据
  2. 管道所有写端已关闭，后续对读端的read()调用会立即返回0（EOF），这种场景下读端也会被标记为就绪。

两种运行场景的逻辑拆解 #

1. 父进程未关闭write_end

fork完成后，管道写端的引用计数为2（父进程、子进程各持有一个）。子进程sleep 1秒后退出，会自动关闭自身持有的写端fd，此时父进程仍持有写端引用，计数为1，管道未进入EOF状态，也没有任何数据写入，因此select判定读端未就绪，一直阻塞到5秒超时，返回0。

2. 父进程提前关闭write_end

父进程fork后主动关闭自身持有的写端，此时管道写端的引用计数只剩子进程持有的1个。子进程1秒后退出，自动关闭自身持有的写端，引用计数归0，管道进入EOF状态，内核直接标记读端为就绪，select检测到状态变化后立即返回1。此时你对读端调用read()会直接返回0，可验证是EOF触发的可读。

关于pselect的混淆点说明 #

你提到的pselect处理信号的逻辑和当前现象是完全独立的两个触发路径：

• 当前select返回是文件描述符自身状态变化触发的正常就绪，和SIGCHLD信号没有任何关系，哪怕你将父进程的SIGCHLD处理逻辑设为忽略，该现象也会正常发生，因此不会出现被信号中断返回-1的情况。
• pselect的作用是解决「同时等待文件描述符就绪 + 信号触发」场景下的竞态问题，避免信号在select调用前触发导致select永久阻塞，和你当前遇到的场景无关。

内容的提问来源于stack exchange，提问作者René paul Debroize