mishimaの日記: イベントディスパッチその3
b. の問題の解決方法としては、
- イベントの積みなおし。
受け取ってしまったイベントを再び積みなおす。
- イベントキューの導入。
イベントへの操作はイベントキューを通して行う。
自分に関係ないイベントはキューから取り除かない。
- 同期的イベント配信。
イベントを要求したときだけイベントが配信される。
また、要求しないイベントは配信されない。
「イベントの積みなおし」は、イベントの順番が保証されないという問題がある
(イベントが送信されたけどまだ受信されていない、パイプに残ったままの
イベントはどうする?)。
「イベントキューの導入」はより洗練された方法であるが、複雑になる点が問題。
で、キューあふれなどの問題によって、欲しがっていたイベントが届かない可能性もある。
クライアント側を単純に、ということを考えると、
「同期的イベント配信」が一番よいように思う。
まあこれはキューを完全にサーバ内に含めてしまっただけなので、
キューあふれの問題は依然として起こりうるのだが。
----
c. は要するにアレだ、シングルスレッドでの複数ストリームの取り扱いと同じ問題だ。
単純な解決法は、select (poll でもいいけど)のような操作を導入すればいい。
でも、もっと単純に、ストリーム同士が結合してしまった方がらくちんだ。
ストリームに対して結合操作ができる方がいいよなあ。
結合操作には3種類考えられる。
- フィルタを通して結合する方法。
あとからもう一個ストリームを追加する、なんてことはできない。
新たなストリームが作成されたように見える。
コマンドとして実装可能。
- 環境を新たに作る方法。
あとからストリームの追加はできない。
既にあるストリームをにイベントが追加されたように見える。
コマンドとして実装可能。
- スレッドを使う方法。
あとからストリームの追加もできる。
既にあるストリームをにイベントが追加されたように見える。
コマンドとして実装できない(内部コマンドになる)
外部との互換性を考えりゃフィルタか環境として実装すべきなんだろうが…
ううむ。
d. もほとんど同じ問題を抱えてる。
むー、フィルタと内部コマンドの両方で実装、っていうのが、いいのかな。
----
xgsh なんて名前だけど、XML はいらないような気がしてきた。
かわりにどんどん esound に対応したくなってきた。
イベントディスパッチその3 More ログイン