mirror of
https://git.vladimir.cc/vladimir/ewsdr.git
synced 2026-08-25 17:27:32 +00:00
6aa4db3cb84d5c2b23918ec6322e89ee90afd1bd
Шаг 4 остановки сервера намеренно ждёт клиентские потоки с прокачкой CheckSynchronize — Stop зовут из потока контроллера, и клиентский поток может как раз висеть на FController.Invoke, то есть на TThread.Synchronize к этому самому потоку. Шаги 2 и 3 при этом делали глухой WaitFor, хотя тик-поток ходит той же дорогой: ReapClients → Disconnected → HandleDisconnect → StopTxOf → Invoke. Проверка CanInvoke у адаптера от этого не спасает: она читает Stopping ДО входа в Synchronize, а FStopping поднимается в начале Stop — значит клиент, отвалившийся ровно в момент снятия галки «Enable TCI server» (или закрытия приложения), успевает проскочить в это окно. Дальше тик-поток стоит в Synchronize, главный — в FTickThread.WaitFor, и таймаута ни у того, ни у другого нет: приложение висит намертво. Общий JoinPumped: ждём Finished, прокачивая очередь (Sleep, если зовут не из главного потока), и только потом WaitFor + FreeAndNil. Finished в FPC взводится ПОСЛЕ DoTerminate, поэтому финальный WaitFor уже не может застать чужой Synchronize и не блокирует. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Languages
Pascal
96.3%
Python
3%
Shell
0.6%