Node.jsのプラットフォーム抽象化ライブラリlibuv
Node.jsは、WindowsのIOCPによる非同期I/Oに対応するのを機に、プラットフォーム抽象化層を分離して別のライブラリにまとめるようだ。これには、c-ares(非同期DNSリクエストライブラリ)やlibevのような外部ライブラリも同時に含まれている。(BSDL)
nmoshは次のバージョンではWindowsのIOCPとMacOS X/FreeBSDのkqueueによる非同期I/Oをサポートする予定で、同様の抽象化層を自前で持っている(ただしCではなくScheme側で切っている)。libuvのようなライブラリに外注するのは良いアイデアに思えるけど :
- Node.jsはシングルスレッドを前提にしたデザインであるため、(おそらく)libuvはスレッドセーフでない。
- nmoshは"Schemeを使って(EthernetやUSBの)パケットを操作する"ところに力点を置くので、バイトストリームを前提としたlibuvのAPIだと収まりが悪い
という地味な問題がある。
ただ、現実的な問題として、Windowsのような非同期 I/Oは他にSolaris(やAIX)にくらいしか存在しないので、基本的にはlibuvくらいの表現力でたいていのOSの非同期I/O機能は表現できてしまう。。
Windowsとその他の非同期I/Oの違いは↑のプロジェクトWebページとして紹介されている http://tinyclouds.org/iocp-links.html とか、プレゼンのPDF http://nodejs.org/nodeconf.pdf に詳しい。
IOCPはI/O Completion Portであり、I/Oの完了をうけとれるのが大きなポイントになっている。epollやkqueueではデータの読み書きReadyしか来ないので、実際の読み書きを後から行う必要がある。一応POSIX AIOとして標準は存在するが、例えばLinuxは普通のスレッドを使ってエミュレーションしている。
非同期I/Oサーバがスレッドセーフであるべきかどうかは地味だけど重要な問題だろう。nmoshの場合はOpenCLのような演算デバイスの抽象化APIもサポートしなければならないので、スレッドセーフにしない選択肢は無いが。。(OpenCLはプロセス間で演算器を共有することを考慮していないし、IOCPのようなOS自体の非同期I/Oインフラと混合することはできないため、スレッドで待ち受ける部分はどうしても残ることになる。)
ただ、node.jsのようにネットワークI/Oに対象を絞り、データの処理は他のプロセスに投げるというデザインが許容されるなら、シングルスレッドを前提としたシステムでも十分に機能する可能性が高い。
