Re: Regarding IO Completion ports
A more object oriented approach would be:
void WorkItemReceived(WorkItem* wi) {
wi->HandleWork();
}
The WorkItem itself knows what to do. In fact it can be a
simple interface (e.g. a class with only pure virtual methods).
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================
"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:%23hh9omM4HHA.4400@TK2MSFTNGP06.phx.gbl...
"SD" <sd@nospamgroup.com> wrote in message
news:8B63FEB6-0C70-4FC7-8AD9-84C8A78EE50C@microsoft.com
I'm designing a MW server, which handles connections at the FE and BE.
So there are FE socket connections and BE socket connections.
Different worker threads are spawned off depending on whether data is
received from the FE or BE. Hence, I think I need 2 IOCPs to do the
job. How can I do it using a single IOCP?
Something like this (pseudocode):
void WorkItemReceived(WorkItem* wi) {
if (wi->FromFE())
HandleFEWork(wi);
else
HandleBEWork(wi);
}
That is to say, the difference between FE and BE data is not in threads
that are processing it - it's in the data itself. The same thread can
happily handle FE data now, and then BE data later.
That's the whole idea behind a thread pool: individual threads are
stateless and can process any piece of work at any time. All the necessary
state is stored in the work item itself.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925