Russian Qt Forum

Существует такой паттерн, как Active object, который предназначен для организации асинхронного вызова методов целевого класса путем формирования поверх него обертки.
В недрах самой обертки присутствует планировщик задач, поток исполнения и т.п.

Если интерфейс класса имеет, например, вид

C++ (Qt)
class Passive // Implementation
{
public:
    Result doSomething ();
}
 

то можно сформировать обертку вида

C++ (Qt)
class Active // Proxy
{
public:
    Future< Result > doSomething ();
};
 

В этом кратком обзоре все понятно. Метод вызывает законченное действие, ждем результат завершения на Future.

Но далее возник вопрос - Что если метод провоцирует цепочку действий (сценарий) или запускает какой-то событийный цикл (прием данных, например)?
При этом важным является не только факт завершения вызываемого метода (как у Future) , но и порядок происходящих событий (стадии сценария, пакеты принимаемых данных и т.п.).

Реализация для этого случая может выглядеть так

C++ (Qt)
class Active
{
public:
    Future< Result > doSomething ();
    //...
    Events takeEvents ();    
};
 

В этом случае необходимо периодически забирать события у объекта. Есть сомнения в таком решении, так как, если не забрать события, то они могут копиться бесконечно.

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

Может есть другие варианты? Может требуется другой паттерн? Что посоветуете?

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

Насколько мне известно, упомянутый паттерн весьма общий - ну контроллер асмнхронки - вот собсно и все.

Может точнее "фильтровать события" (контроллером)? Ну почему нет, это вполне возможно. Но плохо это или хорошо - "зависит от задачи" (любимое выражение всех сачков  :))

Давайте конкретизируем на примере известной задачи).
Рассмотрим подключение tcp клиента к серверу.
Можно обернуть реализацию сокета Активным объектом ("контроллером асинхронки")

C++ (Qt)
class TcpClient
{
...
    Future< bool > connect ();
...
};
 

Кроме факта подключения/не подключения, получаемого через Future, имеются события изменения состояния TcpClient
По аналогии с Qt, пусть это будет:

Каким лучше способом получить данные события от TcpClient?

Мне эта задача незнакома, с сетью практически не работаю

Наверное как TcpClient (контроллер) получит события изменения статуса. Ну напр связать любимыми слот/сигнал вениками :)

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

Это традиционное решение для таких случаем.
Да, клиент должен понимать, что callback-функция вызывается из контекста исполнителя операции, и для корректной обработки применять возможность своего окружения. Например, класть сообщение о смене состояния в очередь сообщений для дальнейшей обработки и обрабатывать их в своих контекстах.
Затормозить или заблокировать это право клиента. Ему можно даже дать возможность штатно прервать операцию посередине. :)
Это все уже проблемы клиента.

Вместо событий сети, могут быть события GUI (мышиные клики или перемещения, например), или события изменения дерева графических узлов, или события генерации каких-либо данных. Принцип работает в любом случае.


Это собственно и есть вариация callback).

Согласен), это собственно и смущает.


Клиент объекта и сам объект по сути контекстно независимы. Понятия одновременности, вовремя и т.п. для них относительны.
Здесь, скорее всего, уместен термин, "своевременно", а не "вовремя". Хотя и так понятно о чем речь).


С "традиционным решением" не согласен. Бывает по разному. Например, для сети на posix, традиционным является как раз периодический опрос наличия данных ::select, и вычитывания всего, что пришло ::recv.
Или для любого другого межпроцессного взаимодействия, приходится периодически опрашивать какой-нибудь обобщенный ресурс (память, файлы и т.п.).

Но соглашусь, что реализация через callback является предпочтительнее, когда между производителем и потребителем можно организовать прямые взаимосвязи.
Тогда и потребителей может быть много, и каждый из них может сам решить, обрабатывать события списком или по одному и каким образом.
По-началу почему-то показалось, что существует какая-то разница между событиями, порождаемыми Активным объектом, и событиями, порождаемыми каким-то произвольным генератором. Но похоже, что нет).