問題タブ [child-process]

子プロセスのstdinとstdoutのファイル記述子を次のようにリダイレクトしています。ここで、入力記述子でデータが利用可能になるまで子プロセスを待機させたいと思います。現在、入力記述子でデータが利用できない場合、子プロセスはランダムな値（おそらくEOF）を取り、終了します。

以下に示すように、標準入力と非標準のファイル記述子（3または4）の両方から入力を受け取るプログラム「サンプル」があります

現在、execvを使用して子プロセスで上記のプログラム（サンプル）を実行する別のプログラム「Operator」があります。今私が欲しいのは、 "Operator" を介して "Sample" に入力を送信することです。

次のスニペットでは、lsコマンドの出力を入力にリダイレクトしていますが、これは完全に機能します。次のコードを使用して、コマンドの出力を「beejoutput.txt」という名前のファイルwc -lにリダイレクトしたいのですが、機能しません。ls助けが必要。

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 で subprocess モジュールを使用しています。理想的には、単に wait() メソッドを使用してインストールの実行が完了するのを待つだけですが、ドキュメントに記載されているコマンドは実際には子プロセスを生成して実際のインストールを処理します。失敗したコードのサンプル コードを次に示します。

ここに同様の質問があります: Killing a subprocess including its children from pythonですが、選択された回答は子の問題に対処していません。代わりに、待機するアプリケーションを直接呼び出すようにユーザーに指示します。サブプロセスのすべての子を待機する特定のソリューションを探しています。サブプロセスの数が不明な場合はどうなりますか? すべての子サブプロセスが完了するのを待つという問題に対処する回答を選択します。

失敗の明確化: 子プロセスは、wait() コマンドの後も実行を継続します。これは、そのコマンドが最上位プロセス (この場合は「sudo」) のみを待機するためです。この問題で知られている子プロセスの簡単な図を次に示します: Python subprocess module -> Sudo -> runInstaller -> java -> (unknown)

マイクロソフトはここで安全にプレーしました。彼らの記事「Creating a Child Process with Redirected Input and Output」では、次のように述べています。

このプロセスが終了すると、残りの開いているハンドルがクリーンアップされます。
大規模なアプリケーションでのリソース リークを回避するには、ハンドルを明示的に閉じます。

これはまったく役に立たない。ハンドルは？どのプロセスで？

頭を整理したい。

を使用して親プロセスでハンドルが作成されるとSECURITY_ATTRIBUTES.bInheritHandle = TRUE、子プロセスはそれを参照して使用でき、ハンドルは両方のプロセスで同じ値とアクセス権を持ちます。

しかし、それは同じハンドルですか、それともたまたま同じ数値表現を持つコピーですか?

hReadパイプから読み取れるように子プロセスにハンドルを渡し、子プロセスがハンドルを閉じる場合、親プロセスからもハンドルを閉じる必要がありますか? 子プロセスの下からパイプをワイプしませんか?

私の実験では、子がハンドルを閉じた後に子に渡されCloseHandleたハンドルを閉じようとすると、成功が返されます。hReadこれは、はい、閉じる必要があることを強く主張しています。ただし、ここでより堅実なアドバイスをいただければ幸いです。

UNIX ソケット経由で子プロセスと通信するマスター プロセスがあります。マスター プロセスが SIGQUIT を受信したときに、子のソケットに書き込むことができません。子プロセスに、マスターが終了していることを認識させ、正常に終了させたいと考えています。

SIGQUIT トラップ外の通信は、期待どおりに完全に機能します。

問題を再現するサンプル コードを次に示します。CRTL + \ は SIGQUIT を送信することに注意してください。(CTRL + C は SIGINT)

マスター プロセス: test.js

子プロセス: test_child.js

子プロセスは制御不能であり、マスクを使用して SIGKILL と SIGTERM 以外のすべてのシグナルをブロックしています。SIGQUIT トラップ中にソケットに書き込むことができない場合、ソケット以外に通信する別の方法はありますか?

「ps」または「サービスステータス（Linuxの場合）」を使用してプロセスステータスを定期的にチェックするスクリプト、またはフォークしてプロセスを待機するC / C ++で監視プログラムを見てきました...

bash を trap で使用して、SIGCLD が受信されたときにサブプロセスを再起動することは可能でしょうか?

次のアイデアでRedHat Linuxで基本的なスイートをテストしました（そして確かに機能しませんでした...）

開始されたbashスクリプトは、数秒間スリープして、今のところ終了します。

いくつかの問題が観察されました:

• シェルがフォアグラウンドで起動すると、SIGCHLD は 1 回だけ処理されます。シグナル()のようなリセットシグナル処理をトラップしますか?
• スクリプトとその子は SIGINT の影響を受けないようです。つまり、^C で停止することはできません。
• 閉じることができないので、端末を閉じました。台本はHUPらしく、ゾンビの子がたくさん出てきました。
• バックグラウンドで実行すると、スクリプトにより端末が停止しました

...とにかく、これはまったく機能しません。私はこのトピックについてほとんど知らないと言わざるを得ません。誰かがいくつかの実例を提案または提供できますか? そのような使用のためのスクリプトはありますか?

では、bashでwaitを使用するのはどうですか？

ありがとう

3 つのワーカー プログラムを作成する 1 つのプログラムがあります。私の状況での望ましい通信方法は、4 つのプログラムすべてがアクセスできるメモリ バッファを介することです。

子プロセスにポインター、参照、または任意の種類のハンドラーを渡す方法はありますか?

アップデート

3 つの子プログラムは頂点データを変換し、メイン プログラムは主に UI、システム メッセージ、エラーなどを処理します。

4 つのプログラムがコンテキストを共有できるように、OpenCL を活用する何らかの方法があることを願っています。これが不可能な場合は、すべてのプログラムで頂点の配列にアクセスできると便利です。

現在のターゲット プラットフォームは Windows だと思いますが、可能な限りクロスプラットフォームを維持したいと考えています。OpenCL を利用してこれを実装する方法がない場合は、おそらくいくつかの異なるプラットフォーム用にこのコードをラップすることになります。