これは次のことを意味しますperldoc -f syscall
。
問題があります
syscall(SYS_pipe())
。生成したパイプの読み込み先のファイル番号を返しますが、相手のファイル番号を検索できません。。を使用すると、この問題を回避できますpipe
。
しかし、これは確認されていません。他のシステムコールと同様に、両端を完全に検索できますsyscall
。SYS_pipe
perl -e '
require "syscall.ph";
my $p = pack "i2";
syscall SYS_pipe(), $p;
print join(",", unpack "i2", $p), "\n"
'
3,4
Linuxではそうです。いくつかの違いに注意すると、openbsdとSolarisでも同じです(Solarisでは実際にはシステムコールがあるためですpipe2(2)
)syscall 42, $p, 0
。
fs/pipe.c
Linuxカーネルソースコードのコメントは次のとおりです。
/* * sys_pipe() is the normal C calling standard for creating * a pipe. It's not the way Unix traditionally does this, though. */
それでは、「伝統的な」方法は何ですか?これは現代のシステムでもまだ適用されますか?
答え1
Perl文書のこの段落はパール5.004_041997年9月。SYS_pipe
当時、特定のUnixカーネルがどうしたのかはわかりませんが、Unix V6の元の実装ではレジスタに2つのファイル記述子を返し、ライブラリ実装はその値をpipe
整数配列に格納しました。V6pipe(2)
マンページこれを簡単に文書化するには、次のようにします。
(パイプライン = 42.)
システムパイプライン
(r0のファイル記述子の読み込み)
(r1のファイル記述子の書き込み)
メッセージの送信先:Linuxパッチさまざまなsys_pipe
実装を統合することも次のように言及されます。
従来の UNIX 実装では通常、レジスタに 2 つのファイル記述子を返します。
おそらくPerlのコメントは、syscall
伝統的に関数の結果を返すために使用されていたすべてのレジスタ(上記のr0、PCのAX / EAX / RAXなど)がPerlコードから取得できるファイル記述子の読み取りを返すという事実から来ているようSYS_pipe
です。 r1に返された値を読み取れません。
私はまだこの方法でファイル記述子を返す最新のシステムを知りません。また、1997年にどれだけのUnixシステムがこのような動作をしたのかはよく分かりません。少なくともSolaris(2.6)はそうではなかったようです。