- fork
-
Does a fork(2) system call to create a new process running the same program at the same point. It returns the child pid to the parent process,
0to the child process, or undef if the fork is unsuccessful. File descriptors (and sometimes locks on those descriptors) are shared, while everything else is copied. On most systems supporting fork(2), great care has gone into making it extremely efficient (for example, using copy-on-write technology on data pages), making it the dominant paradigm for multitasking over the last few decades.同じプログラムの同じ地点から開始する新しいプロセスを作成するために システムコール fork(2) を行ないます。 親プロセスには、チャイルドプロセスの pid を、 チャイルドプロセスに
0を返しますが、 fork に失敗したときには、undefを返します。 ファイル記述子(および記述子に関連するロック)は共有され、 その他の全てはコピーされます。 fork(2) に対応するほとんどのシステムでは、 これを極めて効率的にするために多大な努力が払われてきました (例えば、データページへの copy-on-write テクノロジーなどです); これはここ 20 年にわたるマルチタスクに関する主要なパラダイムとなっています。Perl attempts to flush all files opened for output before forking the child process, but this may not be supported on some platforms (see perlport). To be safe, you may need to set
$|($AUTOFLUSHin English) or call theautoflushmethod ofIO::Handleon any open handles to avoid duplicate output.Perl は子プロセスを fork する前に出力用にオープンしている全ての ファイルをフラッシュしようとしますが、これに対応していないプラットフォームも あります(perlport を参照してください)。 安全のためには、出力が重複するのを避けるために、 全てのオープンしているハンドルに対して
$|(English モジュールでは$AUTOFLUSH) を設定するか、IO::Handleモジュールのautoflushメソッドを 呼ぶ必要があるかもしれません。If you fork without ever waiting on your children, you will accumulate zombies. On some systems, you can avoid this by setting
$SIG{CHLD}to"IGNORE". See also perlipc for more examples of forking and reaping moribund children.チャイルドプロセスの終了を待たずに、fork を繰り返せば、 ゾンビをためこむことになります。
$SIG{CHLD}に"IGNORE"を指定することでこれを 回避できるシステムもあります。 fork と消滅しかけている子プロセスを回収するための更なる例については perlipc も参照してください。Note that if your forked child inherits system file descriptors like STDIN and STDOUT that are actually connected by a pipe or socket, even if you exit, then the remote server (such as, say, a CGI script or a backgrounded job launched from a remote shell) won't think you're done. You should reopen those to /dev/null if it's any issue.
fork した子プロセスが STDIN や STDOUT といったシステムファイル記述子を 継承する場合、(CGI スクリプトやリモートシェルといった バックグラウンドジョブのような)リモートサーバは考え通りに 動かないであろうことに注意してください。 このような場合ではこれらを /dev/null として再オープンするべきです。
On some platforms such as Windows, where the fork(2) system call is not available, Perl can be built to emulate fork in the Perl interpreter. The emulation is designed, at the level of the Perl program, to be as compatible as possible with the "Unix" fork(2). However it has limitations that have to be considered in code intended to be portable. See perlfork for more details.
Windows のような fork(2) が利用不能なシステムでは、Perl は fork を Perl インタプリタでエミュレートします。 エミュレーションは Perl プログラムのレベルではできるだけ "Unix" fork(2) と 互換性があるように設計されています。 しかしコードが移植性があると考えられるように制限があります。 さらなる詳細については perlfork を参照してください。
Portability issues: "fork" in perlport.
移植性の問題: "fork" in perlport。