日々の破片

fork の話は本当の理由はいろいろあるんでしょうが、実際的な理由は Win32 API の CreateProcess の引数の数や複雑さと比べると納得いくかと思います。fork と exec が別のシステムコールになると、その間に各種の操作をはさめるので、プリミティブとして提供する操作がシンプルで済みます。ところで、この話、ときどきの雑記帖でも見たんですが、元ネタを見逃してる気がします。どこなんでしょう。

なるほど！ 確かに実質的な理由として、それは納得がいきます。（それはそれとして、NT3.1−3.0かも の頃、MSJを読んでいたら、どうせすぐにexecしてプロセスイメージを上書きすることになるから、forkで元のプロセスのメモリーをコピーするのをスキップして効率を上げるというような設計思想を読んだ覚えがあります。それともfork相当のAPIも用意したけど、ヒープに対して書き込みが起きるまでは元のプロセスのヒープをマップして共用させるという話だったかな？ で、リードオンリーにしておくと初回書き込みで例外が起きるから、そこで別メモリーにコピーするとかかも）<br>>元ネタ<br>いやぁ、僕もときどきの雑記帖で見たので、元ネタはわかりません。

気になってマジックガーデンで確認したらSysVがcopy-on-write pageを使ってるのだった。というか、fork以外にプロセスを作る手段は無いとなっている(system startupを除く)から、初めにforkありきの話のような。

System-V 系に限らず、いまどきの UNIX 系 OS は、Linux や *BSD のような独立した実装も含め、すべて copy-on-write を使ってますので、メモリコピーはほとんど起きません。ただ、その場合でも別のページテーブルを用意するコストはかかりますので、NetBSD なんかは、いにしえの vfork システムコールを復活させてすぐに exec する場合の効率向上をはかってます。

あーすみません。わたしははてなのどこかで見かけてふった気がするのですが<br> ＞fork & exec <br>ちょっと履歴から調べてみます。

>すべて copy-on-write を使ってます<br>それはそうでしょうね。これって、386あたりからHWでサポートされるようになったのかな？ （MMUが必要なので単なる68KにはUnixは乗らないけど、68010ならOKとかあったような記憶があるけど）<br>>vfork<br>わからないのでマジックガーデン見ると、仮想記憶を上手に使う4.3BSD由来のシステムコールとしか書いてないなぁ（で、forkがcopy-on-writeするようになったので、捨てる予定とか書いてあるし）

ページングをサポートするMMUならOKでしょうね。> copy-on-write<br>68010+MMUならOKだと思います。68000が仮想記憶をサポートできなかったのは、MMUがないからではなく(68010もMMUは外づけです)、page fault 後に、実行しかけた命令を再開する処理にバグがあったせいだと記憶しています。この問題を回避するために、68000を2つ積んで微妙にクロックをずらして対処していたワークステーションがあったような覚えが…<br>vfork の説明は、下記にあります。アドレス空間をコピーせず、あたらしいスレッドも作らず、どちらについても子プロセスが exec を実行するまでは親プロセスから借り受けます。代わりに、その間親プロセスは止まってます。<br>http://netbsd.gw.com/cgi-bin/man-cgi?vfork+2+NetBSD-current

で、買っただけでろくに読んでなかった4.3BSDの設計を紐解くと、「アーキテクチャ的欠点」とか書かれている（子供が壊せるからだから、アーキテクチャは防御を含むので正しい言い方だと思う）けど、親が止まって子供にメモリーを明け渡すのかぁ。これは速いだろうなぁ。あと、BSDの人たちがcopy-on-writeを考えつかなかったのではなく、VAXのHWが信用できなかったからvforkを作った、となってますね。<br>おもしろいなぁ。ありがとうございます。>sodaさん

あ、被った。けど、ネットで読めるほうが良いな。

>68000を2つ積んで微妙にクロックをずらして対処していたワークステーションがあったような覚えが…<br>Apollo/Domain　昔々、CAD業界ではよく使われてました。当初からネットワーク・ワイドなデマンドページングが出来てたのが凄かった。

なるほど。<br>http://www.st.rim.or.jp/~nkomatsu/mc68k/MC68000.html<br>http://tiki.is.os-omicron.org/tiki.cgi?c=v&p=68000%A4%F22%B8%C4%BB%C8%A4%C3%A4%C6%B2%BE%C1%DB%B5%AD%B2%B1

なるほど、68000でクロックをずらして…というのは違ってたんですね。<br>vfork がアーキテクチャ的欠点というのは、主に美しくないからだと思います。<br>ほとんど似たようなものが fork と vfork で二つあり、しかも vfork の方は、利用に関して非常に注意が必要なあたりが問題なんでしょう。子供が親のメモリ空間を触れるといっても、子供は親のクローンですから、セキュリティ的欠点はありませんし。<br>あと、UNIX原典(ISBN4-89362-014-2)を引っ張りだしてきて確認しましたが、「先行して存在したバークレータイムシェアリングシステムの影響」、「exec 機能は既にあり、fork も実装が容易(アセンブリ言語で27行)」だったからだとありました。原文だと<br>http://cm.bell-labs.com/cm/cs/who/dmr/hist.html<br>の「Process control in its modern form was」で始まるあたりです。

＞fork & exec<br>もしかしたらここかもしれません。<br>http://memo.wnishida.com/?date=20070325#p01

ああ、そういえばそこも読んでましたがすっかり忘れてました。^^; > anonymous さん<br>Rochkind の初版は和訳が出てて (ISBN4-87148-260-X)、UNIXプログラミング環境や、リコーの金崎氏の書かれた本とともに、80年代にUNIXをかじった人間はみんな読んでたんじゃないかと思います。著者のつけてる注がめっぽう面白いです。

あら，時間軸的に，うち経由かと思っていたのですが > ときどきの雑記帳<br><br>http://alohakun.blog7.fc2.com/blog-entry-718.html (4/3 の早朝．というか徹夜明け)<br><br>↓<br>http://www.kt.rim.or.jp/~kbk/zakkicho/07/zakkicho0704.html#D20070403-5<br>(4/3 の夜)<br><br>と，良すぎるタイミングだったので．ちょうど，はてなかどっか他で元ネタがあったのですか ? > きむらさん<br><br>ちなみに僕は，たまたま Inferno について調べていたら，西田さんの件の記事を思い出したから引用しただけであって，特に元ネタとかはありませんでした．

sodaさん、anonymousさん、どうも貴重なお話ありがとうございます。<br>特に、Rochkindのはおもしろそうなんで読んでみます。<br>確かに元ネタはあろはさんっぽいですね。>fork&exec

あろはさんのところも、結局西田さんのとこにつながってるのか。

すげーコメント欄が爆発しとる(^^;<br>調べて記憶をたどった結果ですが、あろはさんの推察で正しいと思います。<br>いつものようにあろはさんに突っ込みいれようと書き始めたけど、肝心な部分を明確な形で<br>覚えていなかったので中途半端に<br>(出典などを)ぼかした形で書いた。ということのようです。<br>皆様お騒がせしました。

fork/exec が分かれていた方が都合がよい例としては、シェルの処理として、3つ以上のコマンドをパイプラインで結ぶ場合がありますよね。この時、パイプラインの両側のハンドルを各プロセスの標準○力へ上書きしなくちゃいけませんが、この処理は、(fork+exec がファイルハンドルDUP機能を持っていない限り) fork後exec前のタイミングにしか入れられなかったりします。<br>(fork前だと dup がバッティングするので)

fork前がだめなのはわかりますが、execした後だめというのは、もう別のプログラムになってしまっているから、という意味ですか？<br>そりゃそうか。確かにそうですね。<br>そこで、シェルの実装に好都合という西田さんの話とつながるのかな？

「exec した後だめ」はご認識のとおりです。シェルではなく、ユーザプログラムの方でファイルハンドルの DUP 処理をしていたら、リダイレクト・パイプラインの魅力は半減ですからね。<br>西田さんの真意については実のところ分かりませんが、そう外してもないんじゃないかなと思います。

>というか、あの後、どう展開するのか知りたいLTだった。<br>http://spidernomic.thilosophy.com/<br>メタマジックゲーム連載時にノミックについて読んだ世代としては、非常にわくわくしながらLTを聴いていたのですが、残念ながら時間切れだった。<br>スライド見たらあの後が面白くなるのに！

あれは口惜しかったですね。