SendNotifyMessage() "queues" messages
-
This is an observation rather than a question - if it's not appropriate I will happily delete it. I was wondering what would happen if multiple calls were made to SentNotifyMessage() (where the receiving window is owned by a different thread) during the period that the receiving thread was still processing the first such message it received. My guess as that the thread would be deemed hung and that SendNotifyMessage() would fail. Wrong! The documentation says "...If the window was created by a different thread, SendNotifyMessage passes the message to the window procedure and returns immediately; it does not wait for the window procedure to finish processing the message." Saying that it "passes the message" I think makes it clear that the message doesn't go into the same queue as messages posted with PostMessage(). I set up an experiment (on Windows 10) where the thread which owns the window 'hangs' itself (simply by sitting in a tight loop waiting for a period time to expire) for a substantial period of time when it first receives a message. The thread which sends the messages sits in a loop continuously sending a large number of messages (using SendMessageNotify). Using TRACE output to monitor what was happening I could see that all of the calls to SendMessageNotify() succeeded and happened whilst the receiver was hung processing the the first message. When that hung period expired it then received all of the remaining sent messages in succession. This worked with 100,000 "queued" messages. I was surprised. Windows obviously queues these messages and can cope with a very large number of them.
-
This is an observation rather than a question - if it's not appropriate I will happily delete it. I was wondering what would happen if multiple calls were made to SentNotifyMessage() (where the receiving window is owned by a different thread) during the period that the receiving thread was still processing the first such message it received. My guess as that the thread would be deemed hung and that SendNotifyMessage() would fail. Wrong! The documentation says "...If the window was created by a different thread, SendNotifyMessage passes the message to the window procedure and returns immediately; it does not wait for the window procedure to finish processing the message." Saying that it "passes the message" I think makes it clear that the message doesn't go into the same queue as messages posted with PostMessage(). I set up an experiment (on Windows 10) where the thread which owns the window 'hangs' itself (simply by sitting in a tight loop waiting for a period time to expire) for a substantial period of time when it first receives a message. The thread which sends the messages sits in a loop continuously sending a large number of messages (using SendMessageNotify). Using TRACE output to monitor what was happening I could see that all of the calls to SendMessageNotify() succeeded and happened whilst the receiver was hung processing the the first message. When that hung period expired it then received all of the remaining sent messages in succession. This worked with 100,000 "queued" messages. I was surprised. Windows obviously queues these messages and can cope with a very large number of them.
Just noting that you appear to be referring to the following SendNotifyMessageA function (winuser.h) - Win32 apps | Microsoft Learn[^] PostMessageA function (winuser.h) - Win32 apps | Microsoft Learn[^] Other than that I will note that everything has limit with computers. So you certainly should not create an architecture/design that relies on something being very large without understanding what that means.
-
Just noting that you appear to be referring to the following SendNotifyMessageA function (winuser.h) - Win32 apps | Microsoft Learn[^] PostMessageA function (winuser.h) - Win32 apps | Microsoft Learn[^] Other than that I will note that everything has limit with computers. So you certainly should not create an architecture/design that relies on something being very large without understanding what that means.