Z>>А если нету таймера? Если все выполняется в одном потоке?

Q>Если писали на Win API или чем-то подобном, то должны понимать, что однопоточность и таймер — не взаимоисключающие вещи.

Да, писал, правда очень давно.
Я понимаю, что есть основной цикл приложения, обрабатывающий события от операционки.
Плюс есть обработчики прерываний.

Z>>То есть: по событию формы вызывается контроллер, контроллер создает презентера и вызывает бизнес-операцию... И все это один поток.
Z>>Как в этом случае "опрашивать" статус вычислений?
Z>>Я то думал, что согласно "чистой архитектуре", бизнес-операция через интерфейс презентера должна сама сообщать о статусе.

Q>Вообще плохой подход.
Q>UI и вычисления в одном потоке — это уровень программ 25 лет назад.
Q>Если деваться некуда, то да, тот или иной вид callback. Вычислительное ядро дергает какой-то интерфейс (слушатель, прогресс, ...) и надо обеспечивать обновление (перерисовку) UI. Весь такой треш с while (PeekMessage(...)), т.к. мы в единственном потоке и не в цикле обработки сообщений, а в стеке вычислительной задачи.

Да именно так. "Моя" среда разработки предоставляет только такой механизм.
Само приложение конечно же работает в цикле. Но мне как разрабочику управление этим циклом не доступно.
Мне доступны только методы-события от элементов управления и какие-то немногочисленные обработчики внешних событий, прерывающие основной цикл.

Только не понял, что вы имеете ввиду про "треш с while (PeekMessage(...))"?
Где должен быть организован этот while? В бизнес-логике?

Не штатными средствами можно попробовать "прикрутить" таймер.
Но если рассуждать "теоретически", то тут такая дилемма...
Для каких-то событий бизнес-логики будет достаточно, если интерейс будет обновляться по таймеру.
Но для некоторых "критичных" событий обновление интерфейса должно срабатывать моментально.

То есть, как мне кажется, в программе должно быть два механизма взаимодействия с UI:
— первый: через опрос состояния бизнес-логики
— второй: через непосредственный вызов методов-реализаций перерисовки UI через интерфейсы, вызываемые из бизнес-логики.
Второй механизм покрывает возможности первого, и делает первый механизм ненужным.
И, как я понимаю, Clean Architecture описывает именно второй способ.

Z>>А если нету таймера? Если все выполняется в одном потоке?

Q>Если писали на Win API или чем-то подобном, то должны понимать, что однопоточность и таймер — не взаимоисключающие вещи.

Да, писал, правда очень давно.
Я понимаю, что есть основной цикл приложения, обрабатывающий события от операционки.
Плюс есть обработчики прерываний.

Z>>То есть: по событию формы вызывается контроллер, контроллер создает презентера и вызывает бизнес-операцию... И все это один поток.
Z>>Как в этом случае "опрашивать" статус вычислений?
Z>>Я то думал, что согласно "чистой архитектуре", бизнес-операция через интерфейс презентера должна сама сообщать о статусе.

Q>Вообще плохой подход.
Q>UI и вычисления в одном потоке — это уровень программ 25 лет назад.
Q>Если деваться некуда, то да, тот или иной вид callback. Вычислительное ядро дергает какой-то интерфейс (слушатель, прогресс, ...) и надо обеспечивать обновление (перерисовку) UI. Весь такой треш с while (PeekMessage(...)), т.к. мы в единственном потоке и не в цикле обработки сообщений, а в стеке вычислительной задачи.

Да именно так. "Моя" среда разработки предоставляет только такой механизм.
Само приложение конечно же работает в цикле. Но мне как разрабочику управление этим циклом не доступно.
Мне доступны только методы-события от элементов управления и какие-то немногочисленные обработчики внешних событий, срабатывающие в момент ожидания ввода от пользователя.

Только не понял, что вы имеете ввиду про "треш с while (PeekMessage(...))"?
Где должен быть организован этот while? В бизнес-логике?

Не штатными средствами можно попробовать "прикрутить" таймер.
Но если рассуждать "теоретически", то тут такая дилемма...
Для каких-то событий бизнес-логики будет достаточно, если интерейс будет обновляться по таймеру.
Но для некоторых "критичных" событий обновление интерфейса должно срабатывать моментально.

То есть, как мне кажется, в программе должно быть два механизма взаимодействия с UI:
— первый: через опрос состояния бизнес-логики
— второй: через непосредственный вызов методов-реализаций перерисовки UI через интерфейсы, вызываемые из бизнес-логики.
Второй механизм покрывает возможности первого, и делает первый механизм ненужным.
И, как я понимаю, Clean Architecture описывает именно второй способ.