回答編集履歴
1
update
test
CHANGED
|
@@ -23,3 +23,33 @@
|
|
|
23
23
|
|
|
24
24
|
|
|
25
25
|
上記の追加質問と、それまでの論点との関連性がイマイチ不明瞭ですが...
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
----
|
|
30
|
+
|
|
31
|
+
改訂後の質問内容へのコメント：
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
> OSレベルでは多重入力はイベント駆動で実装されているわけで、そのイベント駆動をそのままコーディングできるシングルスレッドイベント駆動プログラミングって気持ち良くないですか？
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
|
|
39
|
+
JavaScript／Node.jsのように綺麗なイベント駆動モデルなら（それなりに）賛同できますが、OSレベルにより近いselectやepollによるイベント駆動処理は、とにかく面倒でプログラミングも苦痛です。このあたりはlibuv （Node.jsも同ライブラリ利用）のようなイベント駆動フレームワークが、低レイヤにおける暗部を覆い隠している恩恵と思います。
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
一方でマルチスレッドモデルとして挙げている例は、「微妙なタイミング判定」で確かに排他制御が必要なものの、本質的には「いつ割込判定を行うか」という点のみを問題視しているように見えました。イベント駆動フレームワークは、この判定タイミングを「イベントループ」という形で標準化しただけとも言えます。
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
そういう意味では、マルチスレッドで性能と柔軟性を優先する（設計・デバッグ難易度は上がる）か、イベント駆動で標準化された構造を好む（自由度は低くマルチコア非対応）かという話なのかもしれません。
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
> マルチスレッドプログラミングって難しくないですか？
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
|
|
55
|
+
はい。非同期プログラミングは **本質的に** 難解です。これはイベント駆動モデルであっても、複数I/Oを制御するような非同期処理メインでは似たような難しさがあると思います。イベント駆動をマルチスレッド処理と比べたときの利点は、非決定的要因（≒タイミングに依存した処理結果）が比較的少ないという点でしょうか。
|