🚀 go-pugleaf

Hi,
I finally found another post in a Delphi group by Rob Kennedy (thanks!) that
seems to answer most of my questions. I will quote it here for others with
similar problems:

<quote>

valentin tihomirov wrote:
> function TThread.WaitFor: LongWord;
> var
>   Msg: TMsg;
>   H: THandle;
> begin
>   H := FHandle;
>   if GetCurrentThreadID = MainThreadID then
>     while MsgWaitForMultipleObjects(1, H, False, INFINITE,
>       QS_SENDMESSAGE) = WAIT_OBJECT_0 + 1 do PeekMessage(Msg, 0, 0, 0,
> PM_NOREMOVE)
>   else WaitForSingleObject(H, INFINITE);
>   GetExitCodeThread(H, Result);
> end;
>
> I suppose that main thread somehow prosesses messages. It should be done
to
> remain responsive to user and for the terminating thread that is more
> important to prevent deadlocks. I do not see code like this:
>
> while GetMessage {
>     TranslateMessage();
>     DispatchMessage()
> }
>
> What does effectively unlocks a thread sending a message to another?

When you call SendMessage, the message does not really get processed
immediately. Instead, the system will sometimes wait until you call
GetMessage or PeekMessage. When you do that, the system will deliver all
those sent messages before finally returning a new message from the
message queue. (Queued messages are posted, not sent.)

When TThread.WaitFor uses PeekMessage, it's relying on that secondary
message-delivery behavior, not the primary message-retreival, which is
evident since it uses the pm_NoRemove flag.

So the main thread calls MsgWaitForMultipleObjects and sets it to return
if there are any messages sent to a window in the main thread
(qs_SendMessage), and when that happens, PeekMessage delivers them.

It works this way to help prevent deadlock when WaitFor and Synchronize
are used in the same program. The Synchronize method is implemented by
having the TThread use SendMessage on the main thread. Without the
MsgWaitFormUltipleObject/PeekMessage combination, the main thread would
get stuck waiting for the TThread with WaitForSingleObject, and the
TThread would get stuck waiting for the main threa with SendMessage.

If TThread.WaitFor used the more conventional
Get/Translate/DispatchMessage loop, then it wouldn't really be doing
much "waiting" for the thread anymore.

-- 
Rob

</quote>