When posting a Windows message from a worker thread back to the main thread, our process sporadically receives the "not enough quota" error. Problem is that through extensive tracing we are now quite sure that the main thread's message queue is empty.
This is the configuration:
Regular Windows process, no GUI, hidden main window.
Worker thread creates its own window and message loop.
The two are exchanging messages via PostMessage from time to time. Frequency is in the order of one message per couple of seconds.
I couldn't find any other possible reason for this error in the net than the message queue being filled with 10.000 messages, but as I said, we are quite sure that this is not the case. Are there any other known situations, where this error code can be returned from a PostMessage call?
Related
I have a Win32 MFC app that creates a thread which listens on the RS232 port. When new data is received that listener thread allocates memory using new and posts a message to a window using PostMessage. This carries on just fine and the window handles the incoming data and deletes the memory as necessary using delete. I'm noticing some small memory leaks right as my program closes. My suspicion is that one or two final messages are being posted and are still sitting in the message queue at the moment the user shuts the program and the thread closes before that memory gets properly deleted. Is there a way I can insure certain things happen before the program closes? Can I make sure the message queue is empty or at least has processed some of these important messages? I have tried looking at WaitForInputIdle or PeekMessage in destructors and things like that. Any ideas on a good way to solve this?
I 100% agree that all allocated memory should be explicitly free'd. (Just as you should fixed all compiler warnings). This eliminates the diagnostic noise, allowing you to quickly spot real issues.
Building on Harry Johnston's suggestion, I would push all new data into some kind of a queue and simply post a command "check the queue", removing and freeing data in the message handler. That way you can easily free everything left in the queue before exiting.
For a small utility, that leak might be acceptable - but it might cover other causes that are less benign.
PostMessage does not guarantee delivery. So other options are
using a blocking SendMessage
add the data to a deque, use Post Message to notify the receiver new data is available
(Remote code review: if PostMessage returns false, do you delete the memory right away?)
The folks arguing to not worry about it have a valid point. The process is about to end, and the OS will release all the memory, so there's not much point in spending time cleaning up first.
However, this does create noise that might obscure ongoing memory leaks that could become real problems before you application exits. It also means your program would be harder to turn into a library that could be incorporated into another app later.
I'm a fan of writing clean shutdown code, and then, in opt builds, adding an early out to skip the unnecessary work. Thus your debug builds will tell you about real leaks, and your users will get a responsive exit.
To do this cleanly:
You'll need a way for the main thread to tell the listener thread to quit (or at least to stop listening). Otherwise you'll always have a small window of opportunity where the main thread is about the quit just as the listener does another allocation. The main thread will need to know that the listener thread has received and complied with this message. Only then, can the main thread go through the queue to free up all the memory associated with the last messages and know that nothing more will arrive.
Don't use TerminateThread, or you'll end up with additional problems! If the listener thread is waiting on a handle the represents the serial port, then you can make it instead wait on two handle: the serial port handle and the handle of an event. The main thread can raise the event when it wants the listener to quit. The listener thread can raise a different event to signal that it has stopped listening.
When the main thread gets the WM_QUIT, it should raise the event to tell the listener to quit, then wait on the event that says the listener thread is done, then use PeekMessage to pull any messages that the listener posted before it stopped and free the memory associated with them.
Windows 8, x64.
Using overlapped Windows sockets Api with IOCP.
Noticed an unexpected behavior with sockets:
For example, a call to DisconnectEx returns an error WSAENOTCONN but later I receive an event in GetQueuedCompletionStatusEx for exactly this disconnect (like it was still scheduled regardless of returned error).
Same happens with AcceptEx (with different error returned, e.g. WSAEINVAL).
I was expecting the IOCP event to be scheduled only for pending operations (returned error code WSA_IO_PENDING), but not other errors.
EDIT: My question is: can IOCP events be scheduled by the system even if calls to DisconnectEx/AcceptEx return an error (WSAGetLastError) that is not WSA_IO_PENDING?
Thank you!
IOCPs tend to flood you with statuses at seemingly odd times, including after you thought the handle was closed... The solution I used for this was to do a PostQueuedCompletionStatus() with a custom OVERLAPPED parameter to indicate "closed for real now" after I had closed the handle. Then any queued system statuses would be processed, and when I got the custom OVERLAPPED I knew I could free all my internal buffers related to the handle.
The answer for the above question is no. The problem I had is I messed up scheduling several IOCP events on the same overlapped structure which resulted in this strange behavior.
What happens when a window is destroyed while there are still messages pending for it?
Consider the following scenario:
There are three threads, A, B, and C. Thread C owns a window.
Threads A and B use SendMessage to post messages to the window. The message from A arrives first. While C is processing the message from A, it destroys its window using DestroyWindow.
What happens to the message from thread B? Does the call by thread B to SendMessage return?
How does this work internally?
According to MSDN, DestroyWindow "[...], flushes the thread message queue, [...]". I was not sure whether this meant processing the messages or dumping them, so I tried. It turned out to be the latter: all pending posted messages are removed from the queue and ignored. As for non-queued messages: in my tests the pending SendMessage call returned and set the last error to ERROR_INVALID_PARAMETER - 87 (0x57).
In principle, what you're proposing to do isn't safe. There's no way for thread C to guarantee that thread B has already sent the message; if the window is destroyed before thread B sends the message, and if the window handle happens to get reused in the meantime, thread B might wind up sending the message to the wrong window, which might be in a different application.
The best practice would be to make sure that all threads have been informed that a particular window handle has become invalid before calling DestroyWindow.
However, practically speaking, the risk of the handle being reused at just the wrong time is very low. If it is not plausible to inform the other threads ahead of time, you are unlikely to get into trouble as a result. I believe that kicsit is right in asserting that the message will not end up waiting in thread C's message queue, although the documentation does not explicitly promise this as far as I can tell.
The general question, is if I post several messages to the windows message pump from a separate worker thread, will they appear at their destination in the order I sent? ie..
::PostMessage(m_hUsers, WM_BULKPROCESS, 0, 0);
// ... some processing here ...
::PostMessage(m_hUsers, WM_BULKDONE, 0, 0);
m_hUsers is a handle (HWND) to a window I'm sending the messages to from my worker thread. So, will WM_BULKPROCESS always show up first in the window (and therefore be processed by the handler in that dialog class), or is it possible for them to get out of order, ie WM_BULKDONE gets processed before WM_BULKPROCESS, even though it was sent last?
There are a few exceptions (like WM_PAINT), but generally, the order of messages is kept.
Imaging trying to make sense of mouse input if messages appeared in the wrong order!
Quote from GetMessage
During this call, the system delivers pending, nonqueued messages,
that is, messages sent to windows owned by the calling thread using
the SendMessage, SendMessageCallback, SendMessageTimeout, or
SendNotifyMessage function. Then the first queued message that matches
the specified filter is retrieved. The system may also process
internal events. 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
Window messages are stored in a queue. So you can rely on FIFO mechanism.
They should be unless you have code in the message pump that specifically dispatch the messages (either intentionally or not) differently e.g. somehow pick two messages and dispatch them out of order. Normally programmers call DispatchMessage for each message in the order you get from the queue.
I suspect the issue is synchronization and not the message queue. If your code allows multitple invocations of the worker thread proc you have to manage this more tightly to know which "instance" of the worker thread is posting the messages.
Have you checked to make sure you only one worker thread executing at a time, or that the m_hUsers window handle is protected from being changed between BULKPROCESS and BULKDONE?
SendMessage can be useful for managing the BULKDONE because it will block until the message has been processed allowing the code invoking the worker thread to synchronize the invokation of worker threads and truely know that one worker thread has finsished before invoking another. Postmessage will not block but remember the time sensitive part of your worker thread is
`// ... some processing here ...
not sending the windows messages.
I have a thread that needs to dispatch a message (a simulated mouse event that it sends using SendInput) as soon as it's generated. I want this to happen in a loop where there is no sleep; adding any sleep hurts performance as I basically want the events to go in to the event loop immediately once they have been generated. Of course I also don't want the loop in the consumer thread to hog all the cpu so I can't just keep it running, although this gives me good performance.
As far as I understand this, the task is to make the consuming thread to wait for something that signals that the producing thread has provided something to dispatch (?) but how to best do this? I think I need something like two mutexes if I want to make the two threads mutually exclusive; consumer waits for the producer and the producer continues as soon as the consumer resumes running? Didn't really get this working so far and I'm really not sure how to best do this; CriticalSections vs. mutexes, something entirely different?
The reason I don't want to call SendInput from the producer thread is that that thread (the 'main thread'?) actually runs in response to a mouse move message, intercepted by a mouse hook, and sending more mouse messages from that thread didn't allow the thread to finnish before the simulated mouse move event was processed, messing things for me. As I suspected, moving the SendInput call to another thread so that the original thread could finish out of the way fixed the problem but now I need to make the consumer more responsive; mouse messages keep coming at a good pace I suppose since just a 1 ms Sleep made the loop too slow and message processing started lagging; all works well if I have no sleep.
Thanks.
Sounds like you want to use win32 event objects instead of mutexes or critical sections. See the docs here. The event functions allow a thread to wait on a condition that can be signaled from another thread.
Windows threads support message queues - usually used for windows messages but completely usable for messaging between worker threads. PostThreadMessage can be used in the Hook Proc to post messages to another thread for processing.
The worker thread can do a normal GetMessage loop to extract messages to process - rather than passing them on to DispatchMessage as you would in a UI thread you simply check the HWND is NULL in the message structure indicating its a thread message, then process the message yourself. In the case of potential message flooding PeekMessage can be used to cull any outstanding messages from the queue.