>>926
dispatcherに専用threadがいるだけで、
その先はportにbindされた非同期methodをpoolされていたthreadに実行させる、
って実装を想定しているんじゃないかな?
実際、I/O完了ポートAPIだって、kernel/dll内threadがdispatchしているわけでしょう?

>>920
file, socket, diviceなどの複数のstreamが、
readableか、writableか、例外が起きてないか調べます。
真であるstreamがあれば復帰して、bit maskが1になります。
acceptで受けるような接続要求も検知できます。(inetdで使っている)

>>923
そんなことはない。
素朴にどんどんthreadを生成すると、SunOS 5の様に強力なthreadをsupportするOSでも
bottle neckになるから、複数のstream待ちを、何本かのselect/dispatcherにまとめて、
別のthreadに管理させる、ってのは、highly multi-threadedなprogrammingの常套手段。
まあ、普通のprogrammerは、滅多にそういうsystem設計する機会ないと思うけど、
知らないし、bottle neckを調べられから、hardwareを増強させて逃げるdesignerも多い。