えーと、そう言う話しじゃないんですが。複数のユーザプロセスが有限の共有資源に同時にアクセスしようとするときに意図的にタイミングをはかると、いとも簡単にデッドロックを起こすことができますよね。資源の管理を行うべき 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などの問題があちこちで分散して生じる恐れがあるということにあります(もっともkern
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
生じますよ。それはユーザープロセス内部の事情であって、カーネルの問題ではありません。もちろん、現行のマルチスレッドライブラリの設計方針が、たまたま(というより当然のことながら)カーネルと同じ設計方針、ostrich algorithm を採用しているだけのことです。
だからといって現実的に解決できない問題ではありません。現にメインフレームの OS ではデッドロックを自動的に検出して、回復する
Re:依存性の循環を真正面から解いて欲しい (スコア:0)
brake-handle 氏が何者なのか想像がついてる私としては、
とてもそんなことは言えないな。
Worse is Better くらい、
知ってるうえでああいう意見を言ってると思うんだがなぁ。
私も、Worse is Better が言い訳として使われるのを気持ち悪く
感じる(でも多くの場合その方が practical なのが悔しくもある)
ので、彼の気持ちはよくわかるがなぁ。
# 「PC? そんなの Toy System だよ。その証拠に、CPU 16 個乗せてみな」
# s/PC/Linux/