« PhrasePicker | top | 計算不可能性を設計する »
2007年05月08日
Event-driven Programming for Robust Software
Events are bad という論文を読んだ(日本語による要約)。
この論文が批判の対象としているのが、"Event Driven Programming for Robust Software"
という論文である。この論文では、Event ドリブンのモデルを使うと
堅牢なソフトウェアが作れると主張している。
両方を理解しておきたかったので、批判されている方(Eventを良しとする方）の訳をしてみた。
訳をする中で、Event vs Threadの議論に関してさまざまなことを知った。
例えばEventとThreadを統合するという試みも、いくつもある。
その中でもHaskellを使った方法( Unifying Threads and Events )などが興味深かった。
歴史の長い議論の一部を楽しんでいただければうれしい。
ちなみに、論文の作者である fDabek氏は
libasync → SFS → OKWS → Tame → Chordと仕事を続けている。
ネットワークプログラミングやる人はP2Pに行ってしまうのか。
ただしfdebek氏の作ったライブラリは、商用で広く使われているということは
まだまだ少ないようだ。 OKWSにはいくつか実績があったが。
以下、sfsliteに含まれるlibasync-mpのTameのサンプルなども見ての感想を述べる。
* 1978年のNeedhmの論文(On the duality of operating system structures
)において、Event vs Threadの議論は終わっていると思う。
* 論文では「色」sfs1では"rendezvous"と呼ばれる方法でMPにおける性能向上を果たそうというのは面白い。
が、実装時に複雑なものを作りすぎている気がする。論文で言っているようなrestrictionが多い単純な状態のほうが良いかも。
* メモリ管理を引き受けて、GCを独自に実装しようとするのはゴテゴテしすぎだと思った。でも仕方ないのかもしれない。。
* C++のコードをちゃんとパースしてC++のコードを出すのもかなり重々しい。yyを使っていることも重々しいが。。
* tameのような非同期プログラミングをちょっとでも楽にしようとする試みは、面白いが、手を出しすぎると悲惨な目に遭う。tameは、そうなりかけている。
* tameではないが Protothreads のアプローチも面白い。
* 何らかのイベントドリブンプログラミングを簡単にする方法を、VCEの次のバージョンで取り込みたいかもしれない。やるとしたらprotothreadsのようなアプローチが良いかもしれない。こっちはGCとかに手を出していない。再利用できないものかな。
== 関連リンク ==
* Why Events are a bad idea
* Why Threads Are a Bad Idea
* Unifying Threads and Events (by Haskell)
* Transactional memory (used in GHC)
* SFS
* OKWS event-based web server
* OKWS Tame2
* GNU pth non-preemptive thread for event-driven programming
Posted by ringo : 2007年05月08日 15:51
トラックバック
このエントリーのトラックバックURL:
http://www.ce-lab.net/blog/mt-tb.cgi/825
言及リンクのないトラックバックは受け付けない設定にしています。
トラックバックスパムがあまりに多いための処置なので、ご了承ください。
