< :前の番号
^ :番号順リスト
> :次の番号
P :前の記事
N :次の記事（自分と同じ返事先を持つ）
|<:スレッドの先頭
>|:次のスレッド
^ :返事先
_:自分への返事
>:同じ返事先を持つ記事（前）
<:同じ返事先を持つ記事（後）
---:分割してスレッド表示、再表示
| :分割して（縦）スレッド表示、再表示
~ :スレッドのフレーム消去
.:インデックス
..:インデックスのインデックス
In article <1092036348.740460.28946.nullmailer / picachu.netlab.jp>,
matz / ruby-lang.org (Yukihiro Matsumoto) writes:
> |違いません。fork/setsid による実装も含めることを想定しています。
>
> そうすると今度は/dev/nullのポータビリティが。
ここでいうポータビリティというのは、どんな懸念なんでしょう?
もし、/dev/null が存在しなかったり null device でなかったりするかもし
れないという懸念だとすれば、これは完全に満足できる解はないんじゃないか
と思っています。
また、4.4BSD や glibc の daemon() も /dev/null を使うわけで、このこと
に関しては、daemon() も状況は同じです。
(glibc の daemon() は major/minor で null device であることを確認する
仕掛けがついているようですが)
でも、/dev/null が存在しない状況で私が想像できるものは、chroot 環境を
設計している時くらいしかなく、かなりレアなケースだと思います。そのため、
/dev/null が存在している時に Process.daemon を使える利点に対し、
/dev/null が存在していない時に Process.daemon が使えない問題はずっと小
さいものだと思います。
まぁ、どうしてもどうしても、というならデータを読む端から捨てていくプロ
セスを作って、そのプロセスに繋げたパイプや socketpair を使うというのが
考えられますが。
> # setsid,fork,/dev/nullを使った実装は手元にはあります。
だとすると、それを組み合わせればいいですかね。
--
[田中 哲][たなか あきら][Tanaka Akira]