I've also have an application where the 10k limit can be reached
relatively often (several times a day, if the app was running 24/7). This
app also sends/receives lots of messages, but the cause of the queue
becoming full is due to "slowness" in the machine, typically when an
another application starts, or due to a temporary blocking operation (such
as opening a dialogue window). In that applications case, an addition
thread is spawned (in C) that sits on one end of the message queue and
blocks on SendMessage - this ensures that the windows queue only has one
message from the internal "queue" thus ensuring that the windows queue
never becomes full.
Is this something that would be a good option for a real GUI threads
implementation? And wouldn't using the option "cure" pre-XP issue, so
maybe it should be turned on by default... to be turned off for performance
only for those apps that know their queues will not suffer overload, or are
willing to allow them to suffer?
To be 100% honest I'm not sure. I know this solution works, and as my
internal queue is a C structure, the C thread that sits on one end the queue
is extremely lightweight. There might be other solutions too.
Jason is correct, for most people I doubt that the message queue would
become full, especially on XP - but when it does happen it's a right pain to
track down the problems it causes. We need to do more testing in real world
situations to see how likely this situation arises, especially on boxes pre
XP.
Cheers,
jez.
