memo/20070305

以前、LinuxというかUnix系で、selectを共通ライブラリで行って各プログラムにやらせない、という方針で成功しているライブラリを見た。ファイルも標準入出力もソケットも、全部共通化して扱えて、使いやすいうえに、シングルスレッドポリシーで貫かれたライブラリであり動作がとても速かった。

Windowsならどうやればうまくいくのか、と最近考えている。

ためしにselectを調べると、WindowsではselectはWinSockの一部として実装されており、標準入出力やファイルを共通に扱えない。
それにWinSockのselectはファイルデスクリプタをゼロ個渡すような使い方はエラーとなってしまうし、rfdとwfdだけでなくefdも使わないと取得できない情報があるし、帰ってきたFDの数がゼロなのにタイムアウトじゃないことがある。端的に行ってUnix系との互換性が非常に悪く、意図したように使えない。

Windows界では非同期I/Oという用語がよく出てくるが、これはバッファの使い方(ライブラリインタフェース)がselect方式とは大きく異なる。
どうも、MSDNライブラリでは非同期I/Oと、同期的だが非ブロッキングなI/O(Unix系でselectでできること)とが混同されていて、それが無用な混乱を招いている気がする。

Windows界の「非同期I/O」は、Unix系での「シグナル駆動I/O」に近いのかも。

Unix系がTCP/IPレイヤやカーネルレイヤでやっていることまで含めれば、同じようなことはできる気がしてきたけど、selectだけじゃなくてopenとかread,writeに相当する処理もラッパを用意しないとだめポ。
また、使うAPIはselectよりWaitForXXXObjects、.netならWaitHandleクラスのほうが適切っぽい。

それならいっそ、selectじゃなくてepollのインタフェースを参考にはできまいか。

調べているときこれに当たったのでちょっとメモ。

リンク	備考
userver project	uはマイクロ（μ）の意味らしい