Jython：subprocess.Popen 耗尽文件描述符
我正在使用 Python 的 Jython 2.51 实现编写一个脚本，该脚本通过 subprocess.Popen 重复调用另一个进程，并使用 PIPE 来传输 stdout和 stderr 到父进程，stdin 到子进程。经过数百次循环迭代后，我似乎用完了文件描述符。
除了 close_fds 之外，Python 子进程文档 很少提及释放文件描述符 选项，描述得不是很清楚（为什么除了 0、1 和 2 之外还要打开任何文件描述符？）。我假设在 CPython 中，引用计数可以解决资源释放问题。在 Jython 中使用 Popen 对象时，确保释放所有描述符的正确方法是什么？
编辑：以防万一，这是一个多线程程序，因此有多个 Popen 进程同时运行。
I'm using the Jython 2.51 implementation of Python to write a script that repeatedly invokes another process via subprocess.Popen and uses PIPE to pipe stdout and stderr to the parent process and stdin to the child process. After several hundred loop iterations, I seem to run out of file descriptors.
The Python subprocess documentation mentions very little about freeing file descriptors, other than the close_fds option, which isn't described very clearly (Why should there be any file descriptors besides 0, 1 and 2 open in the first place?). I'm assuming that in CPython, reference counting takes care of the resource freeing issue. What's the proper way to make sure all descriptors get freed when one is done with a Popen object in Jython?
Edit: Just in case it makes a difference, this is a multithreaded program, so there are several Popen processes running simultaneously.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这仅回答了您问题的一部分，但我的理解是，当您生成一个新进程时，它通常会继承父进程的所有句柄。这包括您正在侦听的打开文件和套接字等内容。
在 UNIX 上，这是使用“fork”的副作用，它在加载新的可执行文件之前复制当前进程及其所有句柄。在 Windows 上它更加明确，但 Python 无论如何都会这样做，以尝试尽可能匹配跨平台的行为。
close_fds 选项如果为 True，则在生成子进程后关闭所有这些继承的句柄，因此新的可执行文件将从头开始。但是，如果您的子进程一次运行一个，并在完成后终止，那么这应该不是问题。
This only answers part of your question, but my understanding is that, when you spawn a new process, it normally inherits all the handles of the parent process. That includes such things as open files and sockets that you're listening on.
On UNIX, that's a side-effect of using 'fork', which duplicates the current process and all of its handles before loading the new executable. On Windows it's more explicit, but Python does it anyway, to try to match the behavior across platforms as much as possible.
The close_fds option, when True, closes all these inherited handles after spawning the subprocess, so the new executable starts with a clean slate. But if your subprocesses are run one at a time, and terminating when they're done, then this shouldn't be the problem.