柔らかい現実時間 (2)

多数の非同期入力を読んで、データをこねこねして、多数の非同期出力に書きだす。データをこねこねする処理を定期的に行う。伝統的で先進的なサーバアプリケーションが直面している問題は、だいたいこのようなものだと断定して間違いなかろう（たとえば、AJAXだったり、メディア合成だったり、ネットワークゲームだったり）。

そもそも、負荷が高かったら現実時間なんて望むらくもない。それでもしばしば望むのだ。負荷が高い場合は特定の処理を優先してほしいと。望んだことを叶えるべく、ウンコな並列処理機構のウンコなオプションを端から試す。よくよく考え直そう。データセンタに走っていって、新しいマシンをぶちこむほうが先だ。

負荷がほどほどだったら、システムが望んだ時間間隔で処理の機会を与えてくれることを期待して良い、わけはない。総体としてのサーバアプリケーションはクライアントアプリケーションより資源を管理しやすいけれど、リアルタイムOSを使わないのならば（使うの？）、完全に資源を管理できはしない（言うまでもない。Linuxカーネル 2.6はリアルタイム性を大幅に改善したけれど）。

望んだ定期的な時間間隔の二分の一の時間間隔で機会を与えてくれるようにとシステムに頼むことにしよう（二分の一はサンプリング定理を盲目的に適用しただけで、どんな時間間隔も気の向くままに）。機会を与えられるたび、現在時刻を調べて定期的に処理するべき処理を行う。

システムにお願いする方法はどうしよう。現実的に言えば、非同期入出力のイベントキュー（つまり、selectとかpollとか、/dev/pollとかkqueueとかepollとか）のタイムアウトの精度で充分だ。非同期入出力が本当に多数だったら、イベントキューはタイムアウトしている余裕はなく、機会はもっとたくさん与えられるだろう。シグナルベースのタイマを使用する場合でも、再入可能性の厄介を避けるためにセルフパイプを使うならば、結局、イベントキューに帰着する。