What have you found for these years?

2009-01-26

EventMachine

(p.s. 這幾天昏天暗地,不是昏睡就是在看 nico 或打前幾篇提到的初音遊戲... zzz)

EventMachine 是 Ruby 界常用來寫 event driven IO 的 library,
我沒用過 Python, 不過我猜應該很類似 Twisted 吧,因為我看過有人在比較。
C++ 的話大概就是用 ACE... 不過我也從來沒用過 ACE 就是了。

http://github.com/eventmachine/eventmachine

其實從來就沒搞懂過 reactor pattern/event-driven 是怎麼一回事。
重點在於我不懂為什麼用這個東西可以神奇地避免 blocking 的問題??
直到我真的去翻 eventmachine 的 source code, 我才忽然間恍然....

感覺好笨 XD 因為看來看去好像每個人都把這當基本常識,我卻一直不知道為什麼。
但總之果然是直接看 source code 最好,東西就放在那,想像可解決不了一切...
雖然看了我才發現,除了那個關鍵點以外,其他的一切都跟我們 cubeat 裡用的
timer 幾乎一模一樣,當然實作和命名上不同,但概念上我是覺得幾乎一樣。

http://github.com/godfat/cubeat

有時候真的覺得很好玩,不約而同會想到同一種解法。

anyway, 這邊我就不講細節了,因為我猜大家都早知道了...? @_@b

我是覺得重點是 select/poll/epoll/kqueue ...
還有 IO 可以輕易分段處理這件事。
我想這應該表示有以下幾件事:

1. callback 絕對不能慢,否則會拖累整個 event loop.
2. 如果 callback 會慢,則 callback 要能夠分段處理。

照這樣說的話,AI 好像就沒辦法做成 event 了喔?
不然就是真的要試著分段,如:

1. data init step 1
2. data init step 2
3. data init step 3
...
n. process data 1
n+1. process data 2
...
n+m. sum-up data
n+m+1. emit action

之類的?

2 retries:

老林 said...

差不多吧,像我的 AI 目前設定 0.4 秒開 thread 來思考一次,
但假設我已知 simulation 會做 100 次,
改用純 timer 的寫法就變成一個 callback 做一次 simulation,並把結果 cache,
0.004 秒跑一趟,跑一百趟後再合併結果。

但我覺得這種寫法是在邏輯簡單的情況下可用,
也就是拆解運算很容易時。感覺就好像以前我們寫 Flash 時還把 actionscript 大量寫在 frame 上,
然後為了某些 delay 視覺效果常常要把 for loop 拆掉,更甚者要把 recursive algorithm 拆掉意思一樣;拆 for loop 簡單啊,拆 recursive algo 就不見得了。

而且拆歸拆,這樣程式雖然省去的 mt 的麻煩,
但在演算法本身一定會看起來較不直觀、甚至也會有較複雜之感 (因為被拆了)
所以我個人覺得在不考量其他因素的情況下 (譬如說某些情況絕對要用 thread 或絕對不能用 thread 之外),
選擇兩者不同的方法只是在搬動複雜度而已。

godfat 真常 said...

嗯,你說得對,日前才想寫一篇講 mt 和 side-effect 之間的關係
現在來寫好了...

Post a Comment

All texts are licensed under CC Attribution 3.0