えーと、そう言う話しじゃないんですが。複数のユーザプロセスが有限の共有資源に同時にアクセスしようとするときに意図的にタイミングをはかると、いとも簡単にデッドロックを起こすことができますよね。資源の管理を行うべき 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:依存性の循環を真正面から解いて欲しい (スコア:1)
補足。kernelの場合、問題を解くために与えられる時間や空間が極端に少ないという問題もあります。kernel stackの8KBさえ、実行単位の設計によってはお荷物になります(だからこそMach 3.0のcontinuationなどが考えられた)。それに比べて、user processであればGB単位の空間があります。また、kernelはuser processをいつでもpreemptできるため、時間がかかる処理を簡単に実
Re:依存性の循環を真正面から解いて欲しい (スコア:0)