ew8bakandClaude Opus 5 6aa4db3cb8 fix(tci): Stop прокачивает Synchronize и на accept/тик-потоках, а не только на клиентских
Шаг 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>
2026-08-20 10:44:28 +03:00
2026-03-09 18:48:24 +03:00
2026-07-15 10:21:23 +03:00
2026-06-25 12:58:07 +03:00
2026-03-09 18:48:24 +03:00
2026-03-05 16:19:26 +03:00
2026-08-05 16:11:57 +03:00
2026-05-24 16:29:13 +03:00
2026-03-05 16:19:26 +03:00
S
Description
No description provided
Readme
12 MiB
Languages
Pascal 96.3%
Python 3%
Shell 0.6%