QtCore зависимость от QCoreApplication

Question

Я пытаюсь использовать Qt в качестве библиотеки (по аналогии с this), потому что я хочу, чтобы повторно использовать классы Qt в некоторых в настоящее время не-Qt приложений, а также в общих библиотеках, как кросс-платформенного клей. Все это не GUI.

Некоторые проблемы легко избежать DirectConnection, некоторые из них могут быть решены с помощью частных петель событий, даже один может работать в потоке с fake QCoreApplication и он работает (последний курорт).

Я хочу знать, какие модули полагаются на работающий экземпляр QCoreApplication и не могут работать без него.

Некоторые из модулей Qt (в QtCore) действительно нуждается в экземпляре QCoreApplication для правильной работы. Например, QTimer полагается на QCoreApplication для отправки событий таймера. Я читал documentation for QtConcurrentRun и, похоже, полагался на глобальный экземпляр QThreadPool. Я собираюсь попробовать и посмотреть, действительно ли выполнение приложения жизненно важно, или, может быть, экземпляр создается при первом доступе или, может быть, нет.

Я собираюсь изучить QCoreApplicationPrivate источник (Windows и Linux на данный момент), но любые подсказки в правильном направлении приветствуются.

Каковы другие функциональные зависимости для основного приложения? Обратите внимание, что это может зависеть от ОС.

Редактировать 1: Спасибо, ответ Кубы. Кажется QCoreApplication цикл событий не требуется для отправки событий таймера и сокета. Так что некоторые модули QtCore требуют и экземпляр QCoreApplication, но нет необходимости иметь запущенный цикл событий приложения.

Answer 1

Вы сталкиваетесь с существованием QCoreApplication с циклом выполнения событий. Эти два являются отдельными понятиями. Вам может понадобиться первое для последнего, но последнему не нужно работать в той же теме, что и первая.

В частности, вам не обязательно звонить qApp->exec(), если у вас нет событий для отправки в потоке, где вы создали QCoreApplication.

Существование QCoreApplication как бы не является проблемой. Вещи становятся более волосатыми с QApplication - вы можете запустить его в не-gui-потоке, но он не переносится и не будет работать на OS X. Я пытаюсь понять, почему это не работает, но я не понимаю есть много времени, чтобы предложить удовлетворительное решение - пока нет.

Это также неправильное представление о том, что цикл событий QCoreApplication должен выполняться для уведомлений сокетов и событий таймера для отправки другим потокам. Цикл событий QCoreApplication не является чем-то особенным. Существует экземпляр QabstractEventDispatcher, специфичный для платформы, который создается для потока при создании экземпляра первого QEventLoop в этом потоке. QEventLoop не знает ничего конкретного о платформе.

Метод QCoreApplication exec() довольно прост и создает экземпляр QEventLoop и, таким образом, создаст экземпляр QAbstractEventDispatcher для платформы.Этот экземпляр не является особенным. Это то же самое, что и любой другой диспетчер событий, созданный в любом другом потоке, насколько мне известно до сих пор чтение кода.

Если все базовые системы окон поддерживали бы его, на самом деле было бы возможно сделать код Qt GUI многопоточным - процесс приема и отправки событий в потоке уже существует как маленький первый шаг. Большим препятствием, возможно, единственным будет библиотека X и ее display lock. Блокировка дисплея была бы очевидной проблемой между потоками. Вам понадобится каждый поток, который хочет поговорить с графическим интерфейсом, открыть отдельное подключение к X-серверу, и я не знаю, есть ли поддерживаемый способ сделать это из Xlib.