Синхронизация через SendMessage

← →
sniknik © (2015-12-17 14:53) [40]

> хотя "как???" тогда непонятно
разве что в CodeSiteLogger Send есть что-то подобное - Application.ProcessMessages;

← →
sniknik © (2015-12-17 15:01) [41]

!!!!
> разве что в CodeSiteLogger Send есть что-то подобное - Application.ProcessMessages;
Проверил -
procedure TForm1.SyncMsg (var Message : TMessage); begin Memo1.Lines.Add("Enter "+IntTostr(GetCurrentThreadId)+":"+IntTostr(Message.WParam)); Application.ProcessMessages; Sleep(100); Memo1.Lines.Add("Leave "+IntTostr(GetCurrentThreadId)+":"+IntTostr(Message.WParam)); Application.ProcessMessages; end;
результат (кусочек, и так очевидно, ну и плюс "жёсткий зависон" исчез(само собой ;), ТС можно по нему ориентироваться, если его код не вешает основной поток то что-то подобное там есть...) -
Enter 3904:3600
Enter 3904:6700
Leave 3904:6700
Leave 3904:3600
Enter 3904:6700
Leave 3904:6700
Leave 3904:6200
Enter 3904:6700
Enter 3904:3600
Leave 3904:3600
Leave 3904:6700
Enter 3904:3600
Leave 3904:3600
Leave 3904:2636
Enter 3904:3936
Enter 3904:6200
Enter 3904:4356
Enter 3904:6700
Enter 3904:3600

← →
Юрий Зотов © (2015-12-17 16:18) [42]

Рассмотрим 4 первых сообщения.

1. Enter 3904:3600 - доп. поток 3600 через SendMessage вызвал обработчик сообщения (это первый вызов) и главный поток 3904 начал этот обработчик выполнять (но еще не закончил).

2. Enter 3904:6700 - в этот момент доп. поток 6700 через SendMessage тоже вызвал обработчик сообщения (это второй вызов) и главный поток 3904 начал этот обработчик выполнять.

3. Leave 3904:6700 - главный поток обработал ВТОРОЙ вызов.

4. Leave 3904:3600 - главный поток обработал ПЕРВЫЙ вызов. Причем вполне успешно - а это означает, что перед п.2 состояние обработчика сообщения было сохранено, а после п.3 - восстановлено.

===============

То есть, имеем вариант 1 в чистом виде (см. [30], [31], [34]). Что и пытаюсь донести.

← →
sniknik © (2015-12-17 17:35) [43]

в итоге Rouse в первом же посте был прав. ;)

и кстати PostMessage в этом случае не помогает. ;( а при малых "таймаутах" еще
и стек быстро кончается (обработчики событий один в один вкладываются, как матрешки)

ИМХО, при PostMessage переполнения стека быть не должно. Доп. потоки только набрасывают сообщения в очередь главного потока, а главный поток эту свою очередь ЛИНЕЙНО разгребает, одно сообщение за другим. То есть, нет вложенности обработки - значит, нет и переполнения стека.

> переполнения стека быть не должно
не было бы, если бы не Application.ProcessMessages; на нем входит в новый цикл обработки в ней читает следующее сообщение очереди, вызывает функцию и т.д. и т.д. фактически получается рекурсия.

Синхронизация через SendMessage Найти похожие ветки