- Broadcasting Messages
- Posted by Torsten Curdt on December 1st, 2003
While searching for a bug I was wondering
if too many messages could eat my system
resources. I am under WinCE but it is a
general question:
Would this eat up my system resources?
while(TRUE) {
PostMessage(HWDD_BROADCAST,UWM_MY_MESSAGE,0,0);
}
AFAIU PostMessage should just fail at a certain
point.
--
Torsten
- Posted by Ali R. on December 1st, 2003
Well the first thing is that the code you have will eatup the entire cpu
time. But as far as too many messages goes, once the message que is filled
up every other message sent will be droped by the system. Hence you can fill
up the message que but you can over fill the message que.
Ali R.
"Torsten Curdt" <tcurdt@web.de> wrote in message
news:bqfdft$213t88$1@ID-37954.news.uni-berlin.de...
- Posted by Tim Robinson on December 1st, 2003
This code is really evil. It fills up every GUI thread's message queue as
fast as it can. I don't know about WinCE, but Big Windows has a limit of
10,000 messages per queue. If this program is posting messages faster than
some thread can dispatch them, it's going to stop any other input messages
reaching that thread. If nothing else, it's going to suck 100% of the CPU
for itself.
--
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/
"Torsten Curdt" <tcurdt@web.de> wrote in message
news:bqfdft$213t88$1@ID-37954.news.uni-berlin.de...
- Posted by Torsten Curdt on December 1st, 2003
Tim Robinson wrote:
Ok, that's what I would exspect too.
I am trying to understand what I am seeing here. It seems like posting
too many messages is eating up my system resources (not the heap) and
my system freezes.
So the example was a bit too extreme. There is of course a delay between
the posts but from what I understood from the answers. Posting too much
is evil! ..but more from a CPU POV ...not from a memory POV
Is the message queue usually in system oder user space memory?
Maybe the message queue size is too big for the memory of the embedded
device?! I haven't used Platform Builder so far and don't know if this
might be a possible explanation ...but if someone knows please let know!
Otherwise I might be better asking this on a platform builder newsgroup.
Thanks
--
Torsten
- Posted by Tim Robinson on December 1st, 2003
"Torsten Curdt" <tcurdt@web.de> wrote in message
news:bqgcqb$22hm1t$1@ID-37954.news.uni-berlin.de...
I don't know. I could guess for Big Windows, but I've got no idea for
Windows CE.
Maybe asking on a specific CE group would be better. But for such high
volumes of data, I wouldn't recommend using individual Windows messages.
Either group messages somehow, or come up with your own messaging scheme
(e.g. shared memory and semaphores).
--
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/
- Posted by Jussi Jumppanen on December 2nd, 2003
Torsten Curdt wrote:
When a a Windows program is running at 100% CPU all it really
means is the Windows application is not processing it's message
queue (ie "this windows is not responding") which is a no no.
But if you change your code to do the following (pseudo code
only):
while(TRUE) {
PostMessage(HWDD_BROADCAST,UWM_MY_MESSAGE,0,0);
// process the windows message queue
if (PeekMessaage())
{
if (GetMessage() != WM_QUIT)
{
TranslateMessage()
DispatchMessage()
}
}
}
the CPU usage for the program should drop below 100%.
Jussi Jumppanen
Author of: Zeus for Windows (All new version 3.90 out now)
"The C/C++, Cobol, Java, HTML, Python, PHP, Perl programmer's editor"
Home Page: http://www.zeusedit.com
- Posted by Tim Robinson on December 3rd, 2003
"Jussi Jumppanen" <jussij@zeusedit.com> wrote in message
news:3FCD0AAA.782A@zeusedit.com...
A process will consume 100% if it never blocks, i.e. if it never calls a
WaitXXX function, a SleepXXX function, or GetMessage.
If there are messages to process (PeekMessage returns TRUE), the thread will
process them as fast as it can and continue. If there aren't any messages to
process (PeekMessage returns FALSE), the thread will call PostMessage as
fast as it can. This is just the same as the OP's code except that it will
process messages for any windows in the thread. That is, this thread's
windows will continue to accept input but the process will still take 100%
CPU.
--
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/