При закрытии приложения из-за несинхронного закрытия потоков событие лога возникает в тот момент, когда форма уже удалена, и переменная memo содержит nil, что приводит к ошибке.


Нельзя закрывать главное окно приложения, пока есть дополнительные потоки. Варианты могут быть например такие:
а) при закрытии главного окна вызывать Free объекту потока (при этом у потока свойство FreeOnTerminate должно быть False), также нежелательно в таком потоке иметь вызовы Syncronize, т.к. может возникнуть взаимная блокировка доп. потока на этом вызове и главного потока на вызове Free.
б) если поток создаётся на короткое время, а потом уничтожается и у него FreeOnTerminate=True, то при закрытии главного окна можно проверять, работает (создан) ли этот поток и на событие OnCloseQuery выдавать на экран MessageBox, мол "у Вас запущен поток попытайтесь закрыть программу чуть позже" (и выставлять CanClose=False).
в) если поток создаётся на короткое время, а потом уничтожается и у него FreeOnTerminate=True, то при закрытии главного окна в событии OnCloseQuery можно всем запущенным потокам сообщать о необходимости закрытия (выставить глобальную переменную, которую постоянно мониторят все доп. потоки, у которых выставлен FreeOnTerminate=True). Далее вывести на экран сообщение "Вы действительно хотите закрыть программу?". Пока пользователь это сообщение нажимает, потоки успеют закрыться. Но здесь головой думать надо, не факт, что это идеальный вариант. Пользователь может и отказаться закрывать программу, тогда у программы не будет доп. потоков, о чём пользователь также желательно будет сообщить :)

Уверен, что у каждого здесь свой рецепт, как правильно завершить программу при наличии доп. потоков! Кто поделится своими рецептами? :)

Вспомнил ещё один вариант, который часто использую:
1) создаёт поток (с FreeOnTerminate=True) и сохраняем ссылку на него в глобальной переменной MyThread
2) в Execute потока мониторим глобальную переменную Stop (если она = True, то делаем Exit)
3) у потока реализуем перегруженный деструктор и в нем после inherited делаем MyThread := nil
4) при закрытии главной формы выставляем Stop=True, далее в цикле проверяем значение в переменной MyThread, допустим 100 итераций по 10 мс (должно хватить). Если переменная MyThread всё ещё имеет значение, то перестаём ожидать поток, но выводим в лог сообщение. Также поступаем со всеми остальными аналогичными потоками.

а) при закрытии главного окна вызывать Free объекту потока (при этом у потока свойство FreeOnTerminate должно быть False), также нежелательно в таком потоке иметь вызовы Syncronize, т.к. может возникнуть взаимная блокировка доп. потока на этом вызове и главного потока на вызове Free.


Судя по коду метода WaitFor, такая блокировка обрабатывается и успешно разруливается.

Я не смог воспроизвести такую проблему. Специально разработал тестовое приложение, в котором создавался доп. поток, в нём в цикле вызывался Synchronize / SendMessage (с паузой Sleep(0)), а в главном потоке таймер, который срабатывал раз в 5 мс и создавал поток либо делал ему Free. Никаких блокировок не было. Проверял на версии 10.3.3.

Всё это хорошо при условии FreeOnTerminate=False. Ежели FreeOnTerminate=True, то обращения к доп. потоку с помощью переменной (MyThread) потенциально опасны, т.к. объект потока может исчезнуть в любой момент, никакой ExitCode в этом случае не спасёт.

Если же поток может отправлять сообщения, то стоит после WaitFor запустить ProcessMessages (а для более чистой обработки лучше даже собственную выборку GetMessage, вычерпывающую только сообщения от потоков). Правда, обработчик при этом должен понимать, что программа завершается, и не делать ничего противоречащего (запуск новых потоков и т.п.)


Стараюсь не использовать метод Application.ProcessMessages, т.к. из-за него слишком уж много граблей. Всегда можно обойтись другими средствами.

А для чего делать выборку сообщений?
Что, разве при вызове WaitFor сообщения могут пропасть?

Кстати, а по какой причине при вызове WaitFor из основного потока не блокируются вызовы SendMessage из доп. потока? Из-за PeekMessage с параметром PM_NOREMOVE?

Одна из недавно обнаруженных проблем, которая возникает из-за Application.ProcessMessages: используем технологию DataSnap, компонент TSocketConnection. Оказалось, что если DCOM-сервер находится не в локальной сети, а через интернет, то Application.ProcessMessages входит в бесконечный цикл и не возвращает управление.

Вот процедура WaitCmd, в которой бесконечно выполняется Application.ProcessMessages:





Поток FThread отвечает за формирование отчёта (через отдельное подключение TSocketConnection, которое создаётся в потоке). Поток тупо вызывает функцию AppServer.CreateReport(...) у TSocketConnection и выставляет флаг IsReady и запоминает результат (отчёт).
На форме WaitForm таймер, который несколько раз в секунду обращается к DCOM-серверу через подключение TSocketConnection, созданное в главном потоке и двигает ProgressBar.

Для формирования отчёта главный поток вызывает функцию GetReport:

Мы очень много времени потратили на исправление различных багов в модуле SConnect.pas. Но в итоге мы своего добились - оно заработало.