Re: What is the overhead of using windows messages?

From:

"Mark Salsbery [MVP]" <MarkSalsbery[MVP]@newsgroup.nospam>

Newsgroups:

microsoft.public.vc.mfc

Date:

Fri, 25 Jul 2008 11:02:41 -0700

Message-ID:

<esURoCo7IHA.1196@TK2MSFTNGP05.phx.gbl>

"Nick Schultz" <nick.schultz@flir.com> wrote in message
news:eWMrvVn7IHA.1420@TK2MSFTNGP06.phx.gbl...

After getting a running prototype of my packet sniffing app on a
production machine, I have realized that I use the entire cpu under a 40%
bus load.

I figured it must be because of all the messages being sent from the
CANLIB driver to my application. It sends a notification message when the
receive queue leaves its empty state. When no clients are connected, my
apps then simply drops the packets. This process itself takes 100% of cpu
usage on a Celeron 3.0ghz. When a client connects, a new thread is
created to service that client. the thread processesing incoming CAN
packets then sends a message to all the client threads with a pointer to
the new packet. the thread client then serializes the packet, and sends
it off to its client via WM_COPYDATA.

However, with just the backend running (without any clients), my cpu is
already tapped. So I'm trying to find another way to get the job done.

Regardless of the IPC mechanism you use, there's something very suspicious
about a CPU being maxed.
Something seems wrong with the design of the incoming packet handler thread.
How much data is involved per second?

Mark

--
Mark Salsbery
Microsoft MVP - Visual C++

In addition to sending window messages, the CANLIB driver allows
asynchronous notification by using a callback function. I suppose this
function can then place all the packets onto a queue which then can be
read by the client threads. What would be an efficient way of notifing
the client thread that the queue is not empty? (ie no polling \ windows
messages)

second, what would be a faster IPC than using WM_COPYDATA? would using
named pipes be any faster?

Thanks,

Nick