非同期I/O APIの設計がなかなか難しい - .mjtの日記復帰計画

yuniで実用的なプログラムを書くためには、どうしても非同期I/Oライブラリが必要になる。というわけで黙々と設計しているけれど、これがなかなか難しい。 非同期I/Oライブラリの難しさ そもそもOS/処理系毎に別物が必要 "非同期I/Oライブラリなんてlibuv一択だろ"という意見も有るかもしれないし、実際、Node.jsはlibuvのデザインの実用性を証明しつづけていると言える(実際には逆で、Node.jsのOS抽象化レイヤとしてlibuvが実装されている)。が、libuvはカーネル機能の抽象化でしかなく、同じデザインがyuniに適用できるとは限らない。yuniは既にKawa(Java上のScheme実装)やIronScheme(.net上のScheme実装)をターゲットしているので、これらでも動作するような配慮が必要になる。 もし、yuniの非同期I/Oライブラリを単なるlibuvのバイ

[satom9to5]

[I/O][API][設計]

[efcl]

非同期I/O APIの設計。 libuvがカバーする範囲、OSやライブラリによって異なる非同期の抽象化について

[Wacky]

“用途を絞れば、スレッドをサポートしていない処理系でも、いわゆるselect()とnon-blocking I/Oさえサポートしていれば良いことになる。”