えーと、そう言う話しじゃないんですが。複数のユーザプロセスが有限の共有資源に同時にアクセスしようとするときに意図的にタイミングをはかると、いとも簡単にデッドロックを起こすことができますよね。資源の管理を行うべき OS としてはこれはゆゆしき事態なので、そのような状態に陥ったプロセスがあれば速やかに検出し、どちらかのプロセスがにぎっている資源を強制的に解放させてデッドロックを取り除くのが理想です。そうしないと、遅かれ早かれその資源を使いたい他のプロセスにまで影響が及びますから(というようなことは AST などを見れば必ず書いてあると思いま
パッケージ管理が便利になる(?) (スコア:1)
ナニゲに {Free,Open,Net}BSDの Ports って、自分で Makefileをなどをいじることによって、自分の好みに応じた状態のソフトウェアをインストールできるというような楽しみや利便性があって、それはそれで非常にいいことだとは思う。 こんどは Debian のパッケージ管理の方針が取り入れられるとなると、アップデートしそこなっているパッケージのアップデートが半ば自動的におこなえるとか、その辺がありがたく思える。
本当はBSD の中心的なディストリビューションの部分が rpm またはそれ以上のパッケージ管理のシステムの元で管理が行えれば私
依存性の循環を真正面から解いて欲しい (スコア:2, 興味深い)
パッケージの自動管理は聞こえは魅力的です。しかし、パッケージ間の依存性に閉路ができてしまった場合の問題をあまりにnegletしすぎています。
例えば、Cyrus SASLはその認証用データベースとしてLDAPを利用することができます。したがって、OpenLDAPに依存させることができます。一方、OpenLDAPはその認証手段としてCyrus SASLを用いることができます。もしここでOpenLDAPをCyrus SASLに依存させた場合、依存性を両方とも満たすようにパッケージをmakeして欲しいわけです
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
例えば、パッケージ間の依存性の問題などよりも OS としてずっと本質的で深刻なはずのデッドロックの検出と解除に関して、よくあるUnix系のシステムはたいして賢いことはしませんよね？たいてい Ostrich algorithm だと思います。そういう問題
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
それは問題の性質が違います。OSに置けるdeadlock問題は、本来あってはならない問題です。すなわち、debugが終われば忘れることができます。それに対し、packageの問題は、それを解かなければやりたいことができません。複雑な依存性を
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
えーと、そう言う話しじゃないんですが。複数のユーザプロセスが有限の共有資源に同時にアクセスしようとするときに意図的にタイミングをはかると、いとも簡単にデッドロックを起こすことができますよね。資源の管理を行うべき OS としてはこれはゆゆしき事態なので、そのような状態に陥ったプロセスがあれば速やかに検出し、どちらかのプロセスがにぎっている資源を強制的に解放させてデッドロックを取り除くのが理想です。そうしないと、遅かれ早かれその資源を使いたい他のプロセスにまで影響が及びますから(というようなことは AST などを見れば必ず書いてあると思いま
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
あの... そのような事態は、例えばuser threadによるmultithreaddingでも生じませんか? したがって、kernelの問題の場合厄介なのは、
にとどまらず、deadlockなどの問題があちこちで分散して生じる恐れがあるということにあります(もっともkernelを不可分な1つの要素としてしかとらえない人が結構いてわたしは困っているのだが)。それに比べれば、packageの場合は管理機構1個所で問題を解決できる可能性があります。もっと問題が簡単なはずなのに何もしていないのが、toy systemの由縁です。
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
補足。kernelの場合、問題を解くために与えられる時間や空間が極端に少ないという問題もあります。kernel stackの8KBさえ、実行単位の設計によってはお荷物になります(だからこそMach 3.0のcontinuationなどが考えられた)。それに比べて、user processであればGB単位の空間があります。また、kernelはuser processをいつでもpreemptできるため、時間がかかる処理を簡単に実装できます。
こうなると、kernelとuser processでは問題の解き方も変わってきますし、解ける範囲も変わってきます。逆にいえば、同じ範囲の問題が解けてもある場合にはおもちゃにすぎず、別の場合には十分実用になるのです。
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
生じますよ。それはユーザープロセス内部の事情であって、カーネルの問題ではありません。もちろん、現行のマルチスレッドライブラリの設計方針が、たまたま(というより当然のことながら)カーネルと同じ設計方針、ostrich algorithm を採用しているだけのことです。
だからといって現実的に解決できない問題ではありません。現にメインフレームの OS ではデッドロックを自動的に検出して、回復する
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
うーん、これは結局需要があるかという問題にもなってしまう(そしてわたしの場合はたまたまそうなった)のかなぁ... なんかこれ以上議論を続けても得るものがなさそうなので、しばらく棚上げにした方がいいかも。
systematicに勉強したことがないのは事実です。ですが、わたしは日本のPC-Unixの世界で、古い本をいまだに振りまわし、もはや現代の需要に見合わないような理論を信じて疑わない人達がひとたび世界へ出た途端に無残に失敗してしまうという惨状を目のあたりにしています。理論があくまで現実の抽象化であることを忘れ、現実に起きることをよく観察しようとしない人達が残念ながら日本では幅を利かせているんです(OS自体が輸入技術なので半分は仕方ないにしても)。
わたしは、このままでは現実の需要に見合ったものを作ることはできないと考えました。まずは問題となっている現象を観察することから始めなければならない、理論はあくまで後付けに徹する。それを2年ほどやってみた結果、実績も出すことができました(in-core vnodeが不足した場合にname cacheからvnodeを回収し、opened file数のscalabilityを改善。大元に反映済)。理論にしがみつく人達とは全く逆の結果を得たわけです。
OSは自然が作るものではなく、あくまで人間の需要のために作るものです。需要を抜きにして理論を語ってみても、「何に使うの?」という質問が返ってくるだけで世の中の役には立ちません。
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
brake-handle 氏が何者なのか想像がついてる私としては、
とてもそんなことは言えないな。
Worse is Better くらい、
知ってるうえでああいう意見を言ってると思うんだがなぁ。
私も、Worse is Better が言い訳として使われるのを気持ち悪く
感じる(でも多くの場合そ