Как может WndProc () потомка TWinControl из Delphi 6 иногда выполняться вне основного потока VCL?

Существует два способа вызова метода WndProc() компонента основного потока в контексте рабочего потока:

1. рабочий поток напрямую вызывает свойство WindowProc компонента или его Perform() метод.

2. рабочий поток украл право собственности на окно компонента из-за небезопасного использования свойства TWinControl.Handle. Получатель свойства Handle не является потокобезопасным. Если рабочий поток читает из свойства Handle в тот же момент, когда основной поток воссоздает окно компонента (окна TWinControl не являются постоянными - различные условия выполнения могут динамически воссоздавать их, не затрагивая большую часть логики вашего пользовательского интерфейса), тогда существует состояние гонки, которое может позволить рабочему потоку выделить новое окно в своем собственном контексте (и вызвать утечку из основного потока другого окна). Это приведет к тому, что основной поток перестанет получать и отправлять сообщения в своем контексте. Если рабочий поток имеет свой собственный цикл сообщений, он будет получать и отправлять сообщения, таким образом вызывая метод WndProc() в контексте неправильного потока.

Однако мне кажется странным, что стек вызовов не создается. Всегда должен быть какой-то след.

Кроме того, убедитесь, что переменная MainThreadId (или то, что вы используете для отслеживания основного потока) не просто случайно повреждена. Убедитесь, что его текущее значение соответствует начальному значению при запуске.

Еще одна вещь, которую вам следует сделать, - это назвать все экземпляры вашего потока в отладчике (эта функция была введена в Delphi 6). Таким образом, при срабатывании проверки вашего потока отладчик может показать вам точное имя контекста потока, вызывающего ваш метод WndProc() (даже без трассировки стека вызовов), после чего вы сможете искать ошибки в коде этого потока.

Ответ Реми ЛеБо содержит объяснение того, что я сделал неправильно. Я включаю это обновление, чтобы вы могли видеть сложные детали конкретного случая, которые показывают, насколько незаметна ошибка, связанная с сохранением ссылки на элемент управления VCL UI в фоновом потоке. Надеюсь, эта информация поможет вам отладить собственный код.

Часть моего приложения включает созданный мной компонент VCL, который происходит от TCustomControl, который, в свою очередь, происходит от TWinControl. Он объединяет сокет, и этот сокет создает фоновый поток для приема видео с внешнего устройства.

При возникновении ошибки этот фоновый поток отправляет сообщение элементу управления TMemo для целей аудита с помощью PostMessage (). Здесь я допустил ошибку, потому что дескриптор окна (HWND), который я использую с PostMessage (), принадлежит элементу управления TMemo. Элемент управления TMemo находится в той же форме, что и мой компонент.

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

Когда он вызывает PostMessage () с дескриптором TMemo, TMemo находится в состоянии, когда он должен воссоздать дескриптор по требованию, что представляет собой коварный проблемный феномен, который описывает Реми. Это означает, что WndProc () в воссозданном окне TMemo теперь выполняется в контексте фонового потока.

Это соответствует всем свидетельствам. Я не только получаю предупреждение о фоновом потоке в моем переопределенном WndProc (), как упомянуто выше, но и все, что делается в окне TMemo с помощью мыши, приводит к появлению потока сообщений об ошибках # 10038 в TMemo. Это происходит потому, что теперь существует слабосвязанное циклическое условие между TMemo, переопределенным WndProc () компонента и фоновым потоком, поскольку этот поток имеет цикл GetMessage в своем методе Execute ().

Каждый раз, когда сообщение Windows отправляется в элемент управления TMemo, например, из-за движений мыши и т. Д., Оно попадает в очередь сообщений фонового потока, поскольку в настоящее время ему принадлежит окно за TMemo. Поскольку фоновый поток пытается выйти и пытается закрыть сокет на выходе, каждая попытка закрытия генерирует еще одно сообщение # 10038 для отправки в TMemo, сохраняя цикл, потому что каждый PostMessage () теперь по сути является самостоятельной публикацией .

С тех пор я добавил метод уведомления к объекту, который управляет фоновым потоком, который сокет вызывает в своем деструкторе, давая потоку знать, что он уходит и что ссылка недействительна. Я никогда не думал об этом раньше, потому что сокет закрывает фоновый поток во время уничтожения, однако я не жду события завершения из фонового потока. Альтернативным решением, конечно же, было бы дождаться завершения фонового потока. Обратите внимание: если бы я применил этот подход, то этот сценарий оказался бы в тупике вместо того, чтобы приводить к странному поведению с элементом управления TMemo.

[ПРИМЕЧАНИЕ к редактору переполнения стека - я добавляю эту деталь в качестве ответа вместо изменения исходного сообщения, поэтому я не нажимаю ответ Реми, содержащий решение, далеко вниз по странице.]