次期V-FIELD作るぞ - sdyuki-devel

作るぞーと言わないと作らない気がした。

しかし、ParttyやKazuhiki（そしてFDIO）は、このための準備であったのだ！

これからの時代はシングルスレッド＋非同期IO＋Event Drivenだと確信したので、それで行く！

…と言うか、もう同期処理に頭を悩ませたくない…結局コンテキストスイッチで遅くなって報われなさそうだし…

Linux AIOの時に作った↓これをもっと作り込んで、基盤に使う。
http://syuki.skr.jp/aioserver/aioserver-0.0.0.tar.gz

Linux AIOは使えないので、そこはFDIO::Multiplexer（つまりはepoll/kqueue/select）に置き換える。

イベントハンドラのコールに関数ポインタ×２は避けられないかなぁ。仮想関数よりはマシ？

次期V-FIELDは、たぶんV-FIELDではない。

まず名前を変える。

それから、たぶんブロックデバイスにはしない。連想配列（map）にする。

ブロックデバイスとして使うには、このmapの上にブロックデバイスなインターフェースを作ることにする。たとえばチャンク単位でキーにするとか。キーにハッシュをかけなければデータ位置は連続するので、そんなにオーバーヘッドは出ないと思う。

データのストア先はtmpfsにする。こうしておくと後々いろいろ良い。
まずカーネル空間で保持するので、sendfile()で高速。

それから、ファイルシステムに簡単に移行できる。むしろtmpfsにストアすることとファイルシステムにストアすることは、ユーザーランドから見ればどちらも同じ。

現在のV-FIELDは書き込み機能を追加できる設計ではないけど、今度は書き込み機能もインターフェースだけは実装しておく。

書き込みはsocketからread()+mmap()にコピー+ASYNCなmsync()かな？
socketからpipeにsplice→pipeからファイルにsplice？
socketからmmapをvmspliceしたpipeにsplice→ASYNCなmsync()？
read()+Linux AIO write()？
socketからvmspliceしたpipeにsplice→Linux AIO write()？