Kevin, please see the commets inside the body. On 12/11/06, Kevin Sanders <<a href="mailto:newroswell@gmail.com">newroswell@gmail.com</a>> wrote:<div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">One of my coworkers recently observed, that handles associated with a IOCP seem to have CPU affinity, at least sometimes.  In a read completion callback, he posted another read (which is fine and encouraged) and then went off and did a lot of processing which preventing it from calling GQCS for about 20 seconds (very bad).  Even though there were 3 other threads waiting on GQCS, they couldn't pop the completion status for the read from the IOCP even though the read had completed.  Finally, as soon as the original thread came back around and called GQCS, it popped the completion instead of the other threads which had been waiting the whole time. This makes sense, because a running thread that is reading & writing would suffer a CPU cache flush if it changed CPUs.  This was on a true dual CPU box, not a dual core, or hyperthreaded.  I've never read anything that confirms this, but we did see it in this case.</blockquote><div> What' the limit for the running thread for the IOCP?  If you choose 0 for it and the platform is UP, there could be only one thread which can running for the IOCP. I just can't believe it what you have observed. Are you sure the 2nd read operation is completed before the 1st thread back to the GQCS? Do you mean only the 2nd read operation's result  can't be get by GQCS? Does the other IO operations completed during the time be get by GQCS?  best reagards, hanzhu </div></div>