A CLR ezekre a feladatokra a Completion Port-okat használja. Röviden a Completion Port úgy működik, hogy az I/O Manager a Completion Port queue-jába tud aszinkron műveletek eredményeit bepakolni, mint pl amikor a socketről olvas valaki aszinkron, vagy file-ból aszinkron. A Completion Port-ra lehet ráállítani thread-eket, amik felébrednek akkor, amikor jött valami a queue-jába. De olyan okos ez a windows, hogy thread pool-hoz is hozzá tud párosítani egy Completion Port-ot, és akkor a thread pool thread ébred fel.
Van mégegy jó tulajdonsága a Completion Port-nak. Mint a hogy megemlítetted, egyéb módokon (pl ha az ember Completion Routinokat használ az aszinkron hívásaihoz) akkor context switchek meg egyéb csúnya dolgok történnek, de Completion Port-nál nem. Olyan módon van megcsinálva, hogy a Completion Portnál be lehet egyrészt állítani, hogy hány szálat engedjen futni maximum (akkor is, ha több fülel a completion porton). Egy egymagos gépen ezt a számot egyre érdemes rakni, egy négy magos gépen meg négyre. Ez azért jó, mert egyszerre csak egy szál foglalkozik a kész eredményekkel, nem kell őket váltogatni. Amikor ez a szál végez az egyik completion packet feldolgozásával, akkor ha van még a queueban, akkor ő fog vele foglalkozni, mindenféle context switch nélkül. Ha jön be másodpercenként ezer kis csomag, akkor amíg van ideje a threadnek (mert az oprendszer őt futtatja) addig ő fog dolgozni az összesen, context switch nélkül.
A CLR csinál pontosan egy Completion Port-ot, és egy io thread poolt, és összerendeli őket. Ha a BeginReadedbe olyan callback függvényt adtál be, ami nem blokkol, akkor a legnagyobb terhelésnél is egy szál fog minden bejövő kérést kiszolgálni. Bazi hatékony. Amikor lelövöd a socketet, amire kiadtad az olvasó (vagy író) műveletet, akkor is hívodik a rutinod, csak hibával ugrik ki belőle az EndRead. Szóval ha teljesítményigény van, akkor nem jöhet más szóba, csak APM. Található a neten cikk, hogy az APM alatt működö Completion Port mennyivel hatékonyabb, mint a többi. Egy szállal kiszolgál mindent, ha nem blokkol be a szál valami béna waitforsingleobject vagy testvére miatt. Ekkor sem történik nagy baj, indít egy másik szálat a pool-ból, és egy darabig két szál megy, de aztán az egyiket nem engedi szóhoz jutni megint.

Ez nagyon köbalta módszer? Azzal főznék, ami van és erre jutottam.

A while feltételében meg lehet amit akarsz.

A contextswitch eléggé erősnek tűnik nekem. Biztos az?