Связь классов из разных потоков

Отправлять информацию через посылку сигнала, получать в слоте.

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

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

В общем, как-то так, буду благодарен, за любой совет/пинок в нужную сторону.

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

Эт ты ещё не видел как народ выпендривается на платформах, где нету пользовательской очереди сообщений из коробки...

Сигналы, слоты и queued connection (да и даже тупо auto), это всё как раз для таких случаев.

По поводу дополнительных чихов в интерфейсе - ну используй двойную диспетчеризацию и имей один интерфейсный сигнал и слот, которые получают умный указатель на наследник какого нить Information. Вперёд, изобрети систему заново.

Это, конечно же, в разы более понятное dsl чем просто обмен событиями :)

Сарказм?) Ну вообще да, одна связка сигнал-слота для каждого типа сообщения будет более понятна при чтении, но с другой стороны, так нужно каждый раз делать новую связку, когда у нас появляется новый тип сообщения. В общем, свои плюсы/минусы есть у обоих способов.

указав, что доставлять данные необходимо через очередь сообщений

Можно ничего не указывать, AutoConnect же

Ну, кмк, городить какое то околосетевое api, имеет смысл только ради возможности multi/broadcast. Но это настолько редкий случай в бизнесе, что придумать что-то лучше чем модель подписка/оповещение крайне сложно для общего случая.

Иначе - непонятно почему этих акторов столько пиарят на каждой завалящей конфе, но пользуется ими 2.5 человека, включая авторов. А для всего остального есть очереди сообщений(*MQ*).

более понятна при чтении

Для любой фигни лучше делать так, что бы это утверждение было истинно, пока не упрёшься в нефункциональные требования.

этих акторов

По ссылке речь идет не про акторов, а про CSP. Это похожая, но несколько другая штука. Широко используемая и удобная, за примерами в язык Go.

CSP-шные каналы могут быть удобнее сигналов-слотов, во-первых, за счет более низкой связности сущностей (каждая сторона знает только про типы передаваемых данных, но ничего не должна знать друг о друге), и, во-вторых, за счет встроенного механизма back pressure.

Но, если ничего этого в задаче ТС-а не требуется, то в эту сторону можно и не смотреть.

А, тогда ой. Спасибо за пояснения. Про акторов просто накипело :)

Про акторов просто накипело :)

ИМХО, в конце 2000-х акторы были слишком распиарены на волне хайпа вокруг Erlang-а. И хотя сама по себе это вполне себе хорошая «технология», она достаточно специфическая и явно уместна далеко не всегда. Вот здесь в начале речь идет именно об акторах и их применимости.

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

Ну так и сигналы/слоты связываются по сигнатура. Объекты друг про друга ничего не знают.

Back pressure - аргумент.

Ну так и сигналы/слоты связываются по сигнатура. Объекты друг про друга ничего не знают.

А как можно сделать connect в Qt, если объекты друг про друга ничего не знают?

int main(int argc, char** argv)
{
    QApplication app(argc, argv);
    ClassA objectA;
    ClassB objectB;

    QObject::connect(&objectA, ClassA::signalX, &objectB, ClassB::slotX);
    
    int result = app.exe();

    return result;
}

Классы ClassA и ClassB ничего друг про друга не знают. Параметры signalX и slotX должны совпадать.

А по мне норм решение. Для objserver работа с objinfo просто через публичные методы. Другой вопрос: действительно ли нужен второй поток. Неужели производительности не хватит, чтобы оба объекта работали в одном?