YuRockДа, только очень грамотный программист обернёт на всякий случай вызов winapi-шных функций в try...except, а потом еще, после окончания цикла обработки сообщений (и фактического разрушения очереди сообщений), будет надеяться, что повторный

поможет именно "дообработать" оставшиеся сообщения.
Ну всё, пошла чушня.
1) При чем тут winapi-шные функции и try-except? try-except для своего кода, разумеется.
1.1) Вместо постоянной проверки winapi-шных функций на true бывает и Win32Check, к примеру
2) В какой Вселенной "окончание цикла обработки сообщений" означает "фактическое разрушение очереди сообщений"? Очередь жива, пока живет тред.

YuRockДа, я тоже не понимаю, зачем, например, Борланд сделал такое в Forms.pas:


Когда найдешь в этом коде очистку очереди сообщений не-gui потока от отправленных в очередь выделенных кусков памяти - тогда и будем разбираться, почему же это Борланд так сделал
Тут уже без комментариев...
Конечно без комментариев, раз возразить нечего.
Есть и другой вариант - с while PeekMessage(PM_REMOVE), но у меня сделано через статус, уже не помню почему.

С очередью виндовых сообщений есть один слабый момент - если запостить сообщение в момент после того, как отработает цикл очистки, но до убиения хэндла потока. Для избежания этого надо проверять Terminated перед PostMessage.

YuRockНу так и оберни в try-except свой "... process ...", зачем всю гору.
Не придирайся, это наколеночный пример и к тому же это совсем не принципиально
YuRockЭто не так. Во вселенной, которая называется Винда. Все сообщения, полученные после QM_QUIT, будут потеряны навсегда вместе со всеми данными (при чем PostMessage, отсылавшая их, при этом вернет True).
Это как раз не так. То есть это "так" только в случае простейшего цикла begin while GetMessage do ... end;. Если же после цикла GetMessage выполняется цикл очистки, как я указывал, то ничего не теряется. Если хочешь, проверь сам:
В execute:


Где-то вне вторичного потока



YuRockЭто я тебе привел пример в ответ на вопрос
Василий 2Зачем в цикле очистки очереди досрочное прерывание?При чем тут очистка не понятно. Это просто, еще раз, пример "досрочного" (не дожидаясь GetMessage=False) выхода из цикла обработки сообщений.
Зачем мне синтетический пример досрочного выхода? Да и в любом случае, пусть эта проверка сделает Break. Потом она попадет на очистку и все закончится хэппи-эндом. В чем твое возражение-то?

V.Borzovво-первых, забить на теоретические потери памяти при postmessage и слать строки, указав ссылки на них в качестве одного из параметров. Естественно, нельзя послать ссылку на переменную типа string, объявленную в функции, а это должна быть динамически созданная pchar-строка.
Дело вкуса, мне например больше удобен вариант
NewStr(ps);
ps^:=strtosend;
ну и при получении - DisposeStr
автор Удаление памяти, выделенной на строку, производится адресатом.
И не забыть удалить, если PostThreadMessage вернул false.
авторО том, что этот Postmessage не дойдет до адресата, и тот не сможет выделенную дополнительную память отпустить, не беспокоимся, это паранойя.

При должном проектировании это так. По крайней мере, оппонент данного подхода до сих пор не предоставил вменяемых возражений.
авторво-вторых, для обратной связи шлем postmessage потоку. Например, если хотим сказать ему, чтобы он закрылся. Если поток на тот момент уже самоудалился, то, собственно, не смертельно (так ли?)
Конечно не смертельно, PostThreadMessage вернет false и по GetLastError = ERROR_INVALID_THREAD_ID можно будет понять, что он уже помер.
автор, но вот по этой причине обращение к нему напрямую через terminate - нежелательно, если не хотим опять с блокировками зависнуть.

Ничего страшного, если только тред не FreeOnTerminate. terminate просто ставит булевское поле terminated в true и никого не блокирует

YuRockА PostQuitMessage тебе встречать не приходилось? Ну да ладно.
А покажи-ка мне, как через PostQuitMessage послать WM_QUIT другому потоку
авторДавай про цикл очистки не будем, просто вообще, ну не смешно.
Замять тему, когда возразить нечего? Достойный ход, да.
Василий 2Опровергающий один (только один) из моих примеров, когда сообщения могут остаться необработанными.
Из двух примеров один опровергся, а другой насквозь надуман :D

YuRock1. Заметь, опровергся мной, а не тобой, который советовал и продолжает советовать какие-то бредовые "циклы очистки" для разрушенной, закрытой очереди.
1. Доказательства того, что внутри Execute очередь может разрушиться от прихода WM_QUIT, будут (для буквоедов: TerminateThread не рассматривается)? Без доказательств бред - это как раз то, что утверждаешь ты.
2. Твоё опровержение играет малую роль, даже если бы поведение функций было прежним, твой пример все равно бы не сыграл (для буквоедов: рассматриваем цикл очистки второго варианта, с GetQueueStatus).
3. Я всё ещё жду примера, как через PostQuitMessage отправить WM_QUIT другому потоку
автор2. Ты меня спросил: "зачем искусственно прерывать цикл?" Я ответил, что так может быть построена логика программы (и циклы при этом могут быть чужими, в которые не удастся наставить костылей). Привел пример. Он тебе не понравился. Если ты думаешь, что я буду шарашить тебе примеры, пока хоть один из них тебя не "устроит" - ты ошибаешься.

Вообще не в кассу. Я тебя спросил, где в цикле вычерпывания присланных сообщений при завершении потока может встретиться необходимость искусственного прерывания. Ты так ничего и не ответил. Только замечание с окончанием цикла GetMessage по приходу WM_QUIT было корректным, но и то в моем коде это давно предусмотрено, здесь же кусок был написан на коленке.

В общем, подведу итог. Ты обвиняешь меня во лжи (что, кстати, весьма нагло - спишу на юношеский максимализм)
авторЛожь и провокация. В любой момент цикл обработки очереди может завершиться по обычно непредсказуемым для вызывателя PostMessage причинам, не обработав при этом такие и все остальные другие сообщения.
при этом не приведя никаких доказательств того, что грамотный код обработки закроет все возможные причины прерывания (для буквоедов: кроме нештатного вмешательства).
Кроме того, кидаешь еще кучу ложных язвительных утверждений, также являющихся беспочвенными, а на предложение их обосновать скрываешься в кусты.

То, что механизм очистки очереди сообщений не влезает в твой разум - это твои личные трудности, на которые мне начхать. Но не надо выдавать свою некомпетентность за признанные истины - новички могут принять за чистую монету, и дурь размножится. А ее и так хватает.

Кстати, несмотря на хамлоидность, ты натолкнул меня на соображение насчет сообщений, присланных в момент после очистки очереди и до разрушения потока. За это спасибка.

Ох, такое ощущение, что пытаешься религиозному фанатику времен раннего средневековья объяснить теорию эволюции... всё то же самое - полная уверенность в непогрешимости собственных доводов, отсутствие каких-либо доказательств, избирательная глухота на самые неудобные доводы оппонента и перевирание остальных. Подобная беседа совершенно бессмысленна и лишь пустая трата усилий. Тем не менее, надо признать, в процессе всё же удалось набрести на полезные соображения, хоть это и не заслуга YuRock. На всю понаписанную им чушь отвечать не буду, это как об стену горох, возьму только упорно культивируемую им концепцию "разрушения очереди сообщений".

Итак:
YuRockДа, после обработки WM_QUIT очередь закрыта для использования, и даже возобновить ее сначала не удастся.
Вот

Запусти и нажимай на кнопки. После того, как получишь сообщение 'Thread finished', можешь возвращаться xD. Только мышку не протри xD
Наверняка последует заявление, что код написан криво, пробелы расставлены не так и использовать Функцию_X может только полный нуб, в глаза не видевший MSDN и прочая лабуда, но вдруг попадем на редкий момент просветления.

Так, с шелухой разобрались, теперь к полезному - вдруг кто-то придет сюда из поиска и доберется до этого поста.
Организация Execute потока, к которой я пришел, такова:



1. Поток можно завершить как послав сообщение (PostThreadMessage(WM_QUIT)), так и через Terminate.
2. При завершении через Terminate надо обязательно послать "сигнальное" сообщение, т.к. поток может зависнуть на GetMessage, если его очередь будет пуста
3. Нюанс: есть вероятность пропажи сообщений, если они будут отправлены в период между последним ProcessMsg и разрушением потока (ExitThread). Для избежания этого надо убедиться, что Terminated потоку не будут отправляться сообщения - к примеру, можно вообще закрыть ThreadID от доступа извне, вместо него добавив метод PostMessage, который будет проверять флаг Terminated. Разумеется, это не относится к "сигнальному" сообщению из п.2 - его слать нужно в любом случае.
4. Используемая мной ранее функция GetQueueStatus оказалась вещью в себе, вопреки описанию (весьма туманному, кстати) выдающей странные результаты. Например, она может вернуть <>0 при пустой очереди. Поэтому я заменил ее на PeekMessage, которая с такими параметрами идеальна для задачи очистки.
5. Схема Execute, разумеется не фиксирована - можно добавлять try-except в зависимости от задачи, вместо ProcessMsg можно сделать обработку в основном цикле, а чисто удаление выделить в отдельную FreeMsgData и т.д.

YuRockНашёл случайно еще один момент, в котором я немного ошибался: да, действительно, после обработки WM_QUIT теоретически еще можно иногда дождаться сообщений с помощью повторного цикла GetMessage.
Разумеется, только в том случае, если WM_QUIT был послан только один раз.
*фейспалм* случайно, теоретически, иногда дождаться... тут программирование или гадание на кофейной гуще?
Ты вообще осознал суть примера? Она в том, что ловить GetMessage-ом WM_QUIT можно сколько угодно раз, ничего с очередью от прихода этого сообщения не делается.
Можешь закомментить вот эти строки


и пожалуйста, бесконечная отправка WM_QUIT потоку без каких-либо последствий.

YuRockЗамени вот это
...
И увидишь, как неожиданно для тебя начнет работать твой пример.
Заменил. Всё циклится. В выхлопе данные строки:
Debug Output: WM_QUIT received but we're still alive! Got messages: 10 Process Project3.exe (6112) - получили первый WM_QUIT
Debug Output: Cleanup done: message count 1 Process Project3.exe (6112) - съели второй WM_QUIT
Всё ожидаемо. Где удивляться?

YuRockКак красиво и грамотно заставлять поток работать еще неизвестное количество времени после Terminate. Для тех, кто "придет сюда из поиска и доберется до этого поста": не надо использовать эту шелуху. Ваши потоки всегда должны адекватно реагировать на команду "закрыться", а не висеть еще неизвестно сколько.
Теперь я окончательно убедился, что ты существуешь в какой-то иной реальности, где плюшевые единорожки едят радугу.
Во-первых, поток по определению делает что-то продолжительное, он может висеть на ожидании любой синхронной операции либо выполнять суровые вычисления, и команда "закрыться" ему будет сугубо побоку, пока он не доделает задачу. Так что всегда надо закладываться на "неизвестное количество времени после Terminate".
Во-вторых, в данном случае "неизвестное количество времени" - это максимум (T_call + T_case + T_FreeMem)*10000. Это всё занимает десятки миллисекунд. Конечно, есть системы, где и это играет роль, но в них явно не будут создавать и удалять по сотне потоков в секунду. Единственный вариант, когда завершение может затянуться - это если после Terminate потоку продолжают сыпать сообщения, причем с огромной скоростью, сравнимой с (T_call + T_case + T_FreeMem). Но это фича метода, и я указал, как такое предотвратить.
В общем, довод мимо. Этак можно догнаться до того, что программа, дескать, слишком долго закрывается из-за сохранения файла конфигурации - а ну его к черту, юзер в следующий раз заново настроит, ничего с ним не сделается.