Is there any way to programmatically check the priority of a window messages in its message queue?
For example: Some of window messages, WM_PAINT and WM_TIMER are known have the lowest priority and be placed after messages with highest priority.
I'm looking for something by which you can confirm that which one of two messages will have the lowest or highest priority or which message will be sent first or last?
That's just not how it works, Windows messages don't have a priority attached. It is mostly determined by how the message is generated. A message loop dispatches messages in this order:
first any messages generated with SendMessage() are dispatched in the order in which the calls were made
next, any messages generated with PostMessage() and stored in the message queue, in queue order
next, any messages that are synthesized from the window state. WM_TIMER, WM_PAINT and WM_MOUSEMOVE fit this category.
The 'synthesized from the window state' clause is what makes WM_PAINT and WM_TIMER appear to have a low priority. And why moving the mouse rapidly doesn't flood the message queue with mouse messages. That is however not exclusive, you can for example call UpdateWindow() to force a WM_PAINT message to be sent, making it being dispatched with a 'high priority'.
The order is defined in GetMessage / PeekMessage documentation:
If no filter is specified, messages are processed in the following
order:
Sent messages
Posted messages
Input (hardware) messages and system internal events
Sent messages (again)
WM_PAINT messages
WM_TIMER messages
Related
In producer using librdkafka, is it possible to know the number of items produced but not sent yet. I have turned ack off, only interested in sending the message out from the producer. I wish to avoid producing more messages if there are certain number of messages on the send queue(ie the messages produced but not yet sent).
If you set statistics.interval.ms in the producer configuration file, it will start sending the internal metrics in the callback you register.
The callback you can set using the function rd_kafka_conf_set_stats_cb. The statistics are received in the callback in the form of json data.
One the fields from the json data, msg_cnt, tell you the queued messages that you are looking for.
More details are available at https://github.com/edenhill/librdkafka/blob/master/STATISTICS.md
While handling WM_TIMER, I called MessageBox. As a result, a message box popped up with the frequency of the timer. So I believe that the application was trying to continue to process queued/non-queued messages even during MessageBox.
Am I right?
I know that according to MSDN, while an application is sending a message to a different thread from the sending thread, the sending thread will try to process non-queued messages it receives before SendMessage returns --- i.e. before the target thread replies.
Are there any other functions that could try to continue to process queued/non-queued messages before they return, besides MessageBox and SendMessage? I need to know about that to determine whether any functions called in the Window procedure should be reentrant.
Another two relevant questions are
1) Does DispatchMessage not return until the window procedure has returned?
2) Will GetMessage not be called again if the current DispatchMessage hasn't returned yet?
A modal dialog runs its own message loop internally, using the calling thread's message queue. You are calling MessageBox() inside your WM_TIMER handler, so the message loop inside of MessageBox() is receiving and dispatching subsequent WM_TIMER messages while the message box is running.
WM_PAINT messages are not posted to the message queue, but rather when the message queue is empty, the WM_PAINT message is sent to the window procedure (if some area of the window is invalid).
However, are WM_ERASEBKGND messages sent in some similar way, or are they simply posted to the message queue (the documentation don't say anything about this).
It is both, not untypical for Windows messages. It will be sent when the program executes a command like UpdateWindow() or processes a message like WM_SYSCOMMAND that moves or resizes the window. It will be posted when the program has called InvalidateRect().
Same is true for WM_PAINT, normally a "posted" message but only returned by GetMessage() when the message queue is empty. It however will be sent when you call UpdateWindow(), ensuring the window is painted when it returns.
Not taking a dependency on those implementation details is pretty important.
I have a UI thread and another thread, I want to send a user-defined message using PostMessage() from the other trhead to the UI thread.
If the UI thread displays a message box, and then I send the user-defined message, will the message loop of the message box retrieve the user-defined message from the UI thread message queue, and hence the user-defined message will be lost?!
PostMessage() is not a problem. MessageBox() runs its own message loop to make the message box modal, but makes a call to DispatchMessage() and that function makes sure that the correct window procedure gets called for any message that was posted/sent to any window.
You could only make this mistake if you were calling PostThreadMessage() instead. That is never safe if the receiving thread displays dialogs or enters modal loops. Raymond Chen wrote a couple of blog articles about that:
Thread messages are eaten by modal loops
Why do messages posted by PostThreadMessage disappear?
A possible corner-case is posting a message that requires the message loop to process the message instead of the window procedure. Like a shortcut keystroke.
I implemented my own frame decoder to parse the bytes received through a UDP socket (using NioDatagramChannelFactory and ConnectionlessBootstrap) according to our protocol.
Just to follow what is happening in the server while receiving messages, I added trace logs in each callback method of the decoder.
It appears that for almost every message the server receives, we can see that the event "channelInterestChanged" is received twice in the method channelInterestChanged(). The value of the event is first 0 (OP_NONE) then 1 (OP_READ).
I read the documentation about this, but I am still not sure to understand why I receive such events. I first through it was because the receive buffer (or the selector queue) was full, but the server receives this event the same number of times it receives the "messageReceived" event (before the decode() method is called) and all the messages/frames are properly decoded as expected. When messages are missing, I do no see any event at all. In this case it is probably because the receive buffer of the datagram socket is full. But even if I increase this receive buffer, I continue to see these events and to miss messages.
So, I am wondering why for each message received, the server also receives two "channelInterestChanged", one with the OP_NONE value and one with the OP_READ value. Please, takes note also that in the channel pipeline, after my frame decoder, there is an ExecutionHandler and another business-specific handler (which sends a JMS message to an ActiveMQ instance).
Any idea or explanation for me?
Thank you.
When a DownStreamChannelStateEvent fired from a handler (e.g calling channel.setReadable(), channel.setWriteable()), the event will change the channel's nio selector key's interested option in the NioDatagramWorker, later, a UpstreamChannelStateEvent will be fired with changed option (i.e OP_READ or OP_NONE)
Your frame decoder handler receives UpstreamChannelStateEvents because, some other handlers in the pipeline are changing the channel's read interest options (the purpose of calling channel.setReadable/setWriteable is, throttling the read/write to avoid congestion, OutOfMemoryError in the application).
If you have any MemoryAwareThreadPoolExecutor in your pipeline (which monitors the size of the channel memory used), it may suspend or resume reading by calling channel.setReadable() any time if the channel receives messages too fast. You may have to configure the MATPE instance with optimum maxChannelMemorySize, maxTotalMemorySize or disable it by setting it to 0.