问题标签 [child-process]

我在子进程中重定向标准输入和标准输出的文件描述符，如下所示。现在我希望子进程等到输入描述符中的数据可用。目前，如果输入描述符中的数据不可用，则子进程会采用一些随机值（我猜是 EOF）并终止。

我有一个程序“Sample”，它同时从标准输入和非标准文件描述符（3 或 4）获取输入，如下所示

现在我有另一个程序“Operator”，它使用 execv 在子​​进程中执行上述程序（示例）。现在我想要的是通过“Operator”将输入发送到“Sample”。

在下面的代码段中，我将ls命令的输出重定向到完美工作的输入wc -l。现在我还想ls使用以下代码将命令的输出重定向到名为“beejoutput.txt”的文件，但它不起作用。需要帮忙。

我正在尝试从 Node.js 服务器脚本以“虚拟”模式启动 VLC，但是child_process.spawn('vlc',['-I dummy'])在使用 Windows 时使用会为 VLC 的输出生成一个新的控制台窗口。有没有办法防止这种情况发生并通过标准输出 ReadableStream 强制所有标准输出，这样就不会出现“弹出窗口”？

编辑：这个问题与 node.js 无关，这只是我调用它的方式和 VLC 的行为。解决方案如下。

谢谢。

设想：

使用主脚本生成数量不定的子进程，次数不定，以便对服务器执行负载测试。

主脚本最初会生成它可以生成的所有子进程（根据其配置设置），然后当子进程退出时，如果配置请求更多运行，则启动新的子进程。

我看到的是在尝试启动第 83 个子进程时立即失败。83？

我没有做任何事情来明确关闭作为子生成过程的一部分打开的文件，但大概这不是打开代码的工作，而是 child_processes 模块代码的工作？

我很好奇 82 个子进程的神奇数字。这似乎表明节点的限制或我系统上的某些节点组合？

理想情况下，我对这个问题会回答一些知识缺乏了解，或者有人可以建议另一种方法来启动不会遇到此问题的脚本子进程？

我也有兴趣了解 NodeJS 即将到来的 Web Worker API 的状态。有人知道吗？

细节：

• NodeJS v0.4.7
• Mac OS X v10.6.7
• ulimit -n = 256
• 将成功运行的生成子对象的幻数 = 82（意味着 > 82 个生成的 proc 将引发“打开的文件过多”错误）

谢谢你的帮助。

我试图检测安装程序何时从 Python 脚本中完成执行。具体来说，该应用程序是 Oracle 10gR2 数据库。目前我正在使用带有 Popen 的子进程模块。理想情况下，我会简单地使用 wait() 方法来等待安装完成执行，但是，记录的命令实际上会产生子进程来处理实际安装。这是失败代码的一些示例代码：

这里有一个类似的问题：Killing a subprocess including its children from python，但是选择的答案没有解决子问题，而是指示用户直接调用应用程序等待。我正在寻找一个特定的解决方案，它将等待子进程的所有子进程。如果有未知数量的子流程怎么办？我将选择解决等待所有子子流程完成问题的答案。

更清楚地说明失败：子进程在 wait() 命令之后继续执行，因为该命令仅等待顶级进程（在本例中为“sudo”）。下面是这个问题中已知子进程的简单图：Python subprocess module -> Sudo -> runInstaller -> java -> (unknown)

Microsoft played safe here. In their article, "Creating a Child Process with Redirected Input and Output", they are saying:

The remaining open handles are cleaned up when this process terminates.
To avoid resource leaks in a larger application, close handles explicitly.

Which is perfectly useless. What handles? In which process?

I want to get my head around it.

When a handle is created in parent process with SECURITY_ATTRIBUTES.bInheritHandle = TRUE, a child process can see and use it, and the handle has the same value and access rights in both processes.

But is it the same handle, or is it a copy that happen to have same numerical representation?

If I pass a hRead handle to a child process so that it can read from a pipe, and the child process closes the handle, do I also need to close it from the parent process? Will it not wipe the pipe from under the child process?

My experiments show that CloseHandle returns success when trying to close a hRead handle passed to the child after the child has closed it. This argues strongly for Yes, you should close it. However, I would appreciate a more solid advice here.

I have a master process that communicates with children processes via UNIX sockets. I am unable to write to the children's sockets when the master process receives a SIGQUIT. I would like the child processes to know that the master is quitting and to gracefully exit.

Communication outside of a SIGQUIT trap works perfectly as expected.

Here's some sample code that reproduces the problem. Remember that CRTL + \ sends a SIGQUIT. (CTRL + C is SIGINT)

Master process: test.js

Child process: test_child.js

The child processes are out of my control, and use a mask to block out all signals except SIGKILL and SIGTERM. If it simply isn't possible to write to their socket during a SIGQUIT trap, is there another way to communicate with them other then sockets?

我已经看到监视程序在脚本中使用“ps”或“服务状态（在 Linux 上）”定期检查进程状态，或者在 C/C++ 中分叉并等待进程......

我想知道是否可以使用带有陷阱的bash并在收到SIGCLD时重新启动子进程？

我已经按照以下想法在 RedHat Linux 上测试了一个基本套件（当然它没有工作......）

正在启动的 bash 脚本只是休眠几秒钟然后退出。

观察到几个问题：

• 当 shell 在前台启动时，SIGCHLD 将只处理一次。陷阱复位信号处理是否像信号（）？
• 脚本及其子进程似乎对 SIGINT 免疫，这意味着它们不能被 ^C 阻止
• 由于无法关闭，我关闭了终端。剧本似乎是HUP，留下了许多僵尸孩子。
• 在后台运行时，脚本导致终端死机

...无论如何，这根本不起作用。我不得不说我对这个话题知之甚少。有人可以建议或给出一些工作示例吗？有这种用途的脚本吗？

那么在 bash 中使用 wait 怎么样？

谢谢

我有一个程序可以创建 3 个工作程序。在我的情况下，最好的通信方法是通过所有四个程序都可以访问的内存缓冲区。

有没有办法将指针、引用或任何类型的处理程序传递给子进程？

更新

三个子程序正在转换顶点数据，而主程序主要处理 UI、系统消息、错误等。

我希望有某种方法可以利用 OpenCL，以便四个程序可以共享一个上下文。如果这是不可能的，最好能够访问所有程序中的顶点数组。

我想我们现在的目标平台是 Windows，但我们希望它尽可能跨平台。如果没有办法利用 OpenCL 实现这一点，我们可能会退回到为少数不同平台包装这段代码。