io)とselectを使ったマルチプレキシングは違うという話。先日僕がささださんとRailsChatでこのあたりについて聞いた話とか、そのあたりがからんできているのだと思う。読んでいてはっと思いだしたのは、Win32APIの非同期(overlappedの略語としてMSDNでは非同期を当てている)は、これとは異なる意味だということだ。I/O)を指定してファイルのハンドルを作成した場合は、読み取り操作が完了した後、アプリケーション側でファイルポインタを調整してください。APIの説明から)(英語版とは現在内容がちょっと変わってきている。指定したものは、当然オーバーラップIOの対象となり訳語からは非同期IOということになる。ハンドルのオープン時点にどのようなIOを行うかが決定されるということである。FILE_FLAG_OVELAPPEDを指定したハンドルに対して利用できるAPIは、ReadFileとReadFileEx(とWriteFile、WriteFileExだが、以後はReadFile*だけに絞る)の両方だが、どちらを使うかでプログラミングモデルが変わることになる。どちらもオーバーラップ指定したハンドルに対するIOであり、オーバーラップに非同期を訳語として割り当ててあるため、どちらにしても非同期IOとなるわけだ。関数は非同期の操作だけを想定して設計されています。ように、ReadFileでも非同期なIOを利用できるという書き方になる。ReadFileの場合、コールバックルーチンは指定できず、hEventというイベントハンドルを指定する。APIなどにこのイベントハンドルを与えてシグナル状態かどうかでIO完了を判定する。(Win32には、POSIXの意味でのシグナルは存在しないので――バギーだと評されるエミュレートはないわけではないけど――シグナルというのは、モニターのロック状態を意味するというか、要するにWin32のシグナルなんだけど)このReadFileによる非同期IO処理(ということにWin32のAPIの定義からは当然なる)の意味は、yamazさんのところでselect(2)について説明しているIO多重化と同じプログラミングモデルだ。僕が、selectやpollを使ったIOについても非同期と呼ぶのは、Windowsプログラマとしての観点からだったのだな、と思い出した次第。配列に並んでいると最後に完了した5のハンドルが取れてとても困ることになったりする。APIを利用したなぁとか思い出した。#世の中POSIXだけじゃなくてWin32も大きな勢力だから、まあ、どっちでもいいや。blockingと呼ぶ。重要な点は、マルチプレクサを利用するか、コールバックを利用するか、シグナルを利用するかといったプログラミングモデルのどれをどう使うとプログラミングが楽か、あるいは高速化できるか、という点だ。そのへんのバランスによって実装方法を決定し実装する。あと、Win32でプログラミングをする場合には、Webサーバー限定で利用するのでも無い限りパフォーマンスを理由としてスケールさせることはそれほど無いから(例:ATM。それほどどころかスケールさせられるわけもなく)、同期を使うか非同期を使うかコールバックさせるかイベントを使うかとかは、すごく重要な問題で、どれを使ってもプログラミングできたほうが良かったりするので、当然、すごく気にする。ReadFileExとかだと呼び出したスレッドが待ち状態にならないと呼ばれないから))。古い資料だが良い資料だ(9xのサポートがあるので利用できなかったような記憶が)。#世の中POSIXだけじゃなくてWin32も大きな勢力だから、まあ、どっちでもいいや。Portのようなものベースに限定しているので、むしろノンブロッキングなものを非同期と呼んでしまうWin32ネイティブな言い回しのほうが過去のものかなとも思います。Javaも(Unixベンダが多いから当然とは思うけど)マルチプレクサ方式とAsyncIO方式(http://jcp.org/en/jsr/detail?id=203)で呼び方を統一してますし、非同期=AsyncIOとしたほうが誤解は少ないですね。