Да, я об этом думал. Но мне не критична целостность этой переменной, поэтому не стал усложнять. Спасибо.

Добавлю еще вопрос: как оценить ресурсоемкость мьютекса на чтение? В первую очередь, его быстродействие.

Коллеги,
вопрос про азы многопотокового программирования. Думаю, что ответ простой и очевидный ))
Есть глобальная булевая переменная COptions::profilerIsActive.
Переменная может изменяться из разных потоков с использованием мьютекса, например:

C++ (Qt)
{
    QMutexLocker locker(&mutex);
    COptions::profilerIsActive = true;
...
}
 

Она используется в качестве флага для эмитирования сигнала вот так, без блокировки:

C++ (Qt)
    if(COptions::profilerIsActive) {
        emit profilerSig(1, vars.unitId, requestId, QDateTime::currentMSecsSinceEpoch(), vars.hasError(), queueLength());
    }
 

Вопрос: если в момент чтения переменной выполняется ее изменение, может ли это привести к краху программы? То, что я могу прочитать недостоверное значение, меня не волнует - на следующем цикле прочту истинное значение и запущу или остановлю испускание сигнала.

Не понял про "кидает" и про "коннект". Попробуйте это сформулировать другим языком, используя терминологию Qt.
Если же вы имеете в виду соединение сигнал-слот, то его правильнее осуществлять в клиенте.

Что за read, write? Это обработчики сокета?
Судя по всему, вы наследуете QThread. Это не очень хороший способ использования потока. Я вам дал пример, в котором нужный объект передается объекту потока, а запуск выполнения потока вы можете осуществлять, когда вам нужно.

Эти сигналы (servicePollingSig, serviceArchiveSig и т.д.) я оставил для примера, чтобы вы помнили, что межпотоковое взаимодействие осуществляется, как правило, с помощью этого механизма.
В моем случае объекты polling, archiving и т.д. выполняют каждый свою задачу (опрос устройств, создание долговременного архива данных и т.д.), работают каждый со своей периодичностью по таймеру. Поскольку таймер должен создаваться в том потоке, в котором он работает, то для запуска используются упомянутые выше сигналы. Вызываются они тогда, когда это нужно по ходу выполнения программы. Например, у меня - при запуске сервера, после того, как все объекты созданы, распиханы по потокам, прочтена конфигурация:

C++ (Qt)
void CCoreServer::startServices() {
...
    if(COptions::autoPolling)
        emit servicePollingSig(true);
    else
        qInfo("CoreServer: service of polling disabled.");
 
    if(COptions::autoArchiving)
        emit serviceArchiveSig(true);
...
 

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

Если эти данные будут представлять собой объекты каких-нибудь ваших классов, то эти классы нужно будет зарегистрировать в метаобъектной системе Qt, например, так:

C++ (Qt)
Q_DECLARE_METATYPE(CRequestArgs)
...
{
    if(!QMetaType::isRegistered(QMetaType::type("CRequestArgs")))
        qRegisterMetaType <CRequestArgs>    ("CRequestArgs");
...
 

В общем, там еще очень много интересного Поэтому присматривайтесь к сообщениям компилятора.

ЗЫ Не стоит злоупотреблять цитированием сообщений, тем более, когда это и не требуется, - это плохой тон))

Например, так:

C++ (Qt)
class CCoreServer : public QObject
{
    Q_OBJECT
private:private:
    CServicePolling  polling;
    CServiceArchives archiving; 
    CServiceRules    rules;     
    CServiceTransmit transmission; 
 
    QThread pollingThread;     
    QThread archivingThread;   
    QThread ruleThread;        
    QThread transmissionThread;
 
...
 
CCoreServer::CCoreServer(QObject *parent) : QObject(parent),
    polling(this),
    archiving(this),
    rules(this),
    transmission(this)
{
...
 
    polling.moveToThread(&pollingThread);
    QObject::connect(this, &CCoreServer::servicePollingSig, &polling, &CServicePolling::serviceRunSlot, Qt::BlockingQueuedConnection);
    pollingThread.setObjectName("polling");
    pollingThread.start(QThread::HighPriority);
    qInfo ("Polling thread started.");
 
    archiving.moveToThread(&archivingThread);
    QObject::connect(this, &CCoreServer::serviceArchiveSig, &archiving, &CServiceArchives::serviceRunSlot, Qt::BlockingQueuedConnection);
    archivingThread.setObjectName("archiving");
    archivingThread.start();
    qInfo ("Archiving thread started.");
 
    rules.moveToThread(&ruleThread);
    QObject::connect(this, &CCoreServer::serviceRuleSig, &rules, &CServiceRules::serviceRunSlot, Qt::BlockingQueuedConnection);
    QObject::connect(this, &CCoreServer::loadRuleSig,    &rules, &CServiceRules::loadRulesSlot);
    ruleThread.setObjectName("rules");
    ruleThread.start();
    qInfo ("Rules thread started.");
 
    transmission.moveToThread(&transmissionThread);
    QObject::connect(this, &CCoreServer::serviceTransmissionSig, &transmission, &CServiceTransmit::serviceRunSlot, Qt::BlockingQueuedConnection);
    transmissionThread.setObjectName("transmission");
    transmissionThread.start(QThread::LowPriority);
    qInfo ("Transmission thread started.");
 

Сокеты должны создаваться в том потоке, где используются. Соответственно, ключи загружаете там же.
Передача данных - через сигнал/слот.

Нет. Все стили привязаны к виджетам или их свойствам: https://doc.qt.io/qt-5/stylesheet-reference.html

Я имел в виду rules

Можно еще попробовать установить права доступа с использованием RUN и chmod, например:
https://stackoverflow.com/questions/52318133/how-to-change-specific-file-permissions-using-udev-rule

Может, KERNEL не хватает?

Спасибо!

Честно, не понял, чем мне это может помочь Вот если бы вы написали, что 3 Мб - это так, ерунда, а 5 - уже много, то я бы знал, к чему стремиться

Если б это была встраиваемая система, вопроса бы не возникло. Видимо, у меня рефлекс с времен dos 3.0
Но, в общем, посыл я понял.

Коллеги,
размер исполняемого файла 2-3 Мб в Linux при динамической компоновке - это нормально? При каком размере стоит задуматься об оптимизации архитектуры?
А то начинал с полутора Мб, а функционал все растет...