Re: PostMessage and unprocessed messages
"Joseph M. Newcomer" <newcomer@flounder.com> ha scritto nel messaggio
news:8bj0t35tp2t3p9sdfbdc7b3sohjhjontcb@4ax.com...
Note that if you want to flush messages, the concept of flushing messages
is not related
to thread lifetime, but to logical operations outside the thread-thread
communication. For
example, when the mass spectrometer is driving out massive amounts of
trace data, it can
have several thousand messages queued. But the concept of "stop tracing"
is not related
to the thread or its logic; those messages are valid messages. But the
*user* wants to
see the messages stop, and from the user's viewpoint, stopping the message
stream by
discarding all queued messages is a concept of the receiver, not the
sender. So I set a
flag, and when a message is dequeued, I just discard it (and that means
freeing up its
storage). No problem.
OK, I've done something like that (with a flag).
Basically, I have a background worker thread that does long computations and
sends a custom message (we can call it WMU_WORKER_PROGRESS) to the main GUI
thread, after each computation iteration is done.
When the computation is completed, the background worker thread sends
another custom messge (WMU_WORKER_COMPLETED) to the main GUI thread.
The progress message (WMU_WORKER_PROGRESS) has a pointer to some data in
LPARAM. This data is dynamically allocated on the heap using 'new' by the
sender (the worker thread), and it is deleted by the receiver (the GUI
thread) with 'delete'.
Something like this:
DWORD SomeClass::WorkerThreadProc()
{
...
bool running = true;
while ( running )
{
// Stop thread if requested
// ('cancelRequest' is a bool)
if ( cancelRequest )
{
// Stop thread loop
running = false;
continue; // will exit while
}
// Stop loop if computation is completed,
// and send completion message to the main GUI thread (associated
// with 'window' HWND handle)
if ( ...computation completed... )
{
::PostMessage( window, WMU_WORKER_COMPLETED, 0, 0 );
// Stop thread loop
running = false;
continue;
}
// Do thread job for this iteration
...
...
// Report progress to main GUI thread.
// In the progress message, some data is dynamically allocated
// and the pointer passed in LPARAM.
// The receiver (main GUI thread) will delete the pointer
ProgressMsgData * data = new ProgressMsgData();
... set data fields (like percentage of job currently done) ...
::PostMessage( window, WMU_WORKER_PROGRESS, 0, (LPARAM)data );
}
return 0;
}
In the GUI thread, I have message handlers for WMU_WORKER_COMPLETED and
WMU_WORKER_PROGRESS.
Everything works fine, but there is a problem in only one case:
If the dialog-box (the GUI thread) is closed, sometimes some messages are
leaked!
I mean, the dynamically allocated memory is leaked (even if the VS2008 does
not signal that).
I do some tracing from the custom message class constructors and
destructors, and, analyzing the tracing log, I see that sometimes the
destructor calls do not match the constructor calls (i.e. it sometimes
happens that a destructor is not called, so heap memory is leaked).
I think that this is becasue, if the user requests dialog closing (clicking
the 'X' button in the upper right corner of dialog-box), it may happen that
Windows put the WM_COMMAND with IDCANCEL message in the message queue, but
also the background worker thread sends some more WMU_WORKER... messages in
the queue (before closing).
So, when I process the IDCANCEL, I have some pending WMU_WORKER... messages
that I don't process (and so the heap memory is leaked).
(This does not happen always, it happens sometimes - this non-deterministic
nature of multi-threading makes multi-threading debugging and testing
difficult.)
If I had a garbage collector, I would have no problems, in fact the GC would
think about deleting the data associated to unprocessedd WMU_WORKER...
messages.
But how can I discard this data manaully?
If I receive the IDCANCEL, how can I process all the pending (if any)
WMU_WORKER... messages, just to delete the data pointed in LPARAM?
Thanks very much,
Giovanni