北京
1964年10月11日，贝尔实验室的M. D. McIlroy写下了一份备忘录。他想要一种像花园水管一样的东西——需要处理数据时，拧上一段新的管道就行。这个念头后来变成了Unix的管道（pipe），也成了今天命令行里那个竖线符号"|"的源头。
McIlroy的想法很朴素：程序应该像乐高积木一样拼接。一个程序的输出直接变成另一个程序的输入，不需要临时文件，不需要复杂的接口。六十年后，这仍然是系统编程最优雅的设计之一。
但管道的威力不止于方便。它暗含了一种残酷的效率哲学：当没人需要你的输出时，你就该消失。
看看这个例子。seq 2 100000000会打印从2到一亿的所有整数。把它管道给less，屏幕上只显示前几十行，你可以用方向键慢慢浏览。但seq真的在后台默默打印剩下的99999999个数字吗？
没有。用ps aux查看进程，seq已经死了。
用strace追踪系统调用，会看到一串write之后跟着一个SIGPIPE信号。这个信号的含义直白得近乎暴力：你正在往一个管道里写，但管道的另一头已经没人读了。默认行为是立即终止程序。
管道会自动清理不再被需要的生产者。不需要显式的关闭指令，不需要轮询检查，不需要超时机制。当less填满屏幕停止读取时，seq的下一次写入就会触发死刑。
这种设计把资源管理的责任从程序员转移给了操作系统。你不需要担心"如果用户突然退出怎么办"，因为管道已经处理了。代价是程序员必须意识到：写入操作可能以信号中断的形式失败，而你的程序可能随时被杀死。
McIlroy后来用这个思路回应了Donald Knuth的"文学编程"（Literate Programming）。Knuth主张在代码中穿插大量解释性文字，让程序像文学作品一样可读。他写了一个复杂的文本处理程序，混合了排版和算法。McIlroy用六行shell管道完成了同样的任务，没有自定义代码，只有标准工具的组合。
两种哲学的分野在此清晰：Knuth相信单个程序的完备与优美，McIlroy相信系统的组合与涌现。管道是后者的基础设施——它不关心每个程序内部有多精致，只关心它们能否可靠地连接、传递、退出。
这种设计也影响了进程管理的底层机制。Unix的waitpid系统调用会阻塞父进程，直到子进程结束。但如果我们不想用进程间的父子关系，只想知道"某个工作何时完成"，管道提供了一种替代方案：让工作进程在结束时关闭管道的写端，监听端自然能感知到这一事件。这是一种更松耦合的同步方式，不需要共享进程ID，不需要复杂的信号处理。
管道的历史提醒我们：操作系统中最持久的抽象往往不是那些功能最丰富的，而是那些把责任划分得最清晰的。管道不做数据转换，不做错误恢复，不做流量控制——它只做一件事：连接。然后，在连接断裂时，安静地收拾残局。
那个被SIGPIPE杀死的seq进程，正是这种极简主义的牺牲品，也是其有效性的证明。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
