发送初始输入后让子进程接管标准流？Linux/Windows系统级方案问询

我希望启动一个进程时，先向它发送初始输入，之后让它像调用execve那样直接接管父进程的stdin和stdout。以下是用Python写的示例代码（问题本身和编程语言无关）：

import os
import sys
import subprocess
pid = os.getpid()

def printer():
    print(f"[Printer-{pid}] Startup!")
    for line in sys.stdin:
        print(f"[Printer-{pid}] {line.strip()}")

def launcher():
    try:
        print(f"\t[Launcher-{pid}] Sending initial message.")
        # 在另一个进程中启动printer()函数
        child = subprocess.Popen(
                (sys.executable, __file__, "printer"),
                stdin=subprocess.PIPE,
                universal_newlines=True,
                bufsize=1
        )
        child.stdin.write("Initial setup message!\n")
        print(f"\t[Launcher-{pid}] Turning over control.")
        for line in sys.stdin:
            child.stdin.write(line)
    finally:
        child.kill()
        child.communicate()

if __name__ == "__main__":
    if len(sys.argv) > 1 and sys.argv[1] == 'printer':
        printer()
    else:
        launcher()

运行输出（无参数启动） #

[Launcher-24132] Sending initial message.
    [Launcher-24132] Turning over control.
[Printer-29572] Startup!
[Printer-29572] Initial setup message!
message from stdin
[Printer-29572] message from stdin

现有转发方案的问题 #

如果不需要初始输入，直接让子进程继承父进程的标准流即可，但带初始输入时会遇到以下问题：

• 父进程必须持续运行来转发消息，无法提前退出
• 管道数据传递的内核开销翻倍（父进程读入再写出，涉及两次用户态和内核态的拷贝）
• 需要预先设置流的缓冲方式，容易出现缓冲不一致导致的输出延迟或数据丢失

核心需求 #

我需要一种类似「将输入管道与输出管道拼接」的机制，相当于pipe的反向操作——销毁两个文件描述符并直接将它们连接起来。比如类似下面这个（不存在的）Python API：

# 不存在的API示例
os.splice(sys.stdin, child.stdin)

请问Linux/Windows系统是否有这样的特性？如果没有，原因是什么？也可以提及命名管道或Windows下的等效方案。

Linux系统的解决方案 #

Linux没有直接实现「拼接两个文件描述符」的系统调用，但可以通过以下几种方式高效实现需求：

1. 使用splice/vmsplice批量转发 #

虽然不能直接拼接，但可以用splice系统调用在两个文件描述符之间直接传递数据（无需用户态拷贝），将父进程的转发开销降到最低。这种方式下父进程仍需运行，但内核开销几乎可以忽略，且不需要处理用户态的缓冲问题。

2. 使用命名管道（FIFO） #

具体步骤：

• 创建一个命名管道：mkfifo /tmp/init_pipe
• 启动子进程，将其stdin指向该命名管道
• 父进程先向命名管道写入初始数据
• 用dup2将父进程的stdin复制到命名管道的写入端，之后父进程即可退出，子进程会直接从原stdin读取后续数据

3. 使用ptrace（不推荐） #

通过ptrace操控子进程替换stdin文件描述符，但这种方式复杂度高，容易引发兼容性问题，仅适合特殊场景。

Windows系统的解决方案 #

Windows同样没有直接的文件描述符拼接机制，但可以通过以下方案实现需求：

1. 使用命名管道（Named Pipe） #

父进程创建命名管道，启动子进程并让其连接到该管道；父进程写入初始数据后，可将自身的标准输入重定向到管道，或直接关闭父进程的管道句柄，让子进程后续从控制台读取数据。

2. 使用CreatePipe和DuplicateHandle #

创建匿名管道，父进程先向管道写入初始数据；然后通过DuplicateHandle将父进程的stdin句柄复制给子进程，替换子进程原来的stdin管道句柄。这种方式需要在创建子进程时配置STARTUPINFO结构体，或通过Job Object操控子进程句柄。

为什么没有直接的「拼接文件描述符」特性？ #

操作系统未提供该特性的核心原因：

• 文件描述符的进程级语义：文件描述符是进程私有资源，不同进程的文件描述符指向的内核对象（如文件表项）可能有不同的偏移量、权限等状态，直接拼接会破坏状态一致性。
• 并发同步风险：允许任意拼接文件描述符会引入复杂的并发问题，比如多个进程同时操作拼接后的流，难以保证数据顺序和完整性。
• 需求通用性不足：这种场景属于小众需求，操作系统更倾向于提供基础原语（如管道、dup、splice），让用户组合实现复杂功能，而非提供高度特化的拼接机制。

内容的提问来源于stack exchange，提问作者Kaia