Есть и менеджер коннектов свой, и карта коннектов своя. Всё давно работает еще с 2011 года, равновесие очень устойчивое, и вовсе не шаткое. Но от зацикливаний это спасти не может - никакой менеджер в принципе не в состоянии определить, является ли зацикливание нормальным, или оно приведет к перегрузке.

Если кому-то не понятно о чем идет речь (по реакции я вижу, что не понятно...) - надо представлять эту задачу, как электронную схему, собираемую пользователем. Если пользователь создал положительную обратную связь, взяв выход цепочки из трех (или четырех, или десяти...) усилителей и замкнул его на неинвертирующий вход первого усилителя цепочки - при попадании на вход любого сигнала (на самом деле сразу при включении) схема "возбудится" и превратится в генератор, выдающий на частоте собственных колебаний некий периодический сигнал с амплитудой, почти равной питающему напряжению выходного усилителя. А может быть - пользователю именно это и нужно! Может быть, кроме этой очевидной обратной связи (которую программно можно обнаружить), один из усилителей пользовтель вводит в режим ограничения - и вся схема будет генерировать, но с управляемой амплитудой. Это видно пользователю, но это в принципе невозможно обнаружить программно. Зато можно дополнительными средствами обнаружить факт возбуждения, и выключить схему в такой ситуации. Вот и мне нужно обнаруживать факт перегрузки процессора (что является результатом паразитного "возбуждения"), а не переполнение очередей, установку соединений и т.д... Поскольку и переполнение очередей, и установка ЛЮБЫХ соединений могут быть вполне легальными и к перегрузке процессора не приведут.

То есть, никаких обходных путей нет. Нужно определять факт перегрузки процессора своими нитями. Больше ничего не подходит. Я уже просил - не уходить от этого вопроса. Это только бессмысленная трата времени.

Вы в верхнем +1 сообщении сами написали, что хотите невозможного.
Вы хотите дать возможность сознательно сделать зацикливание, но при это избежать зацикливания. Вы уж определитесь чего вы хотите.

PS самый простой пример - пользователь может создать 50 таких рекурсивных генераторов и у вас на любом компе загрузка будет под 100%, но при этом приложение должно работать в штатном режиме.

Если Вы ввели свой термин "перегрузка процессора" никак его не определив, то напрасно Вы рассчитываете на содержательный разговор, все и будет "вокруг да около". Так что фырканье лучше оставить при себе.

Лично я под "перегрузом" понимаю "оверхед", причем солидный, когда нитки вместо полезной работы заняты напр переключениями контекста. Классический пример - создано слишком много ниток. Напр утилита Activity Monitor это прекрасно показывает. Если так то не вижу что обсуждать на форуме - ищите подходящие утилиты для своих платформ и не морочьте голову с доморощенными терминами. Если не так, то поясните какой смысл Вы вкладываете в этот термин, и лучше без нажима, не надо сорить большими жирными буквами.

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

Хотя... чего это я лезу со своими "сплошными оффтопиками"?   Все, умолкаю

Пусть будет оверхед - это слово калька с английского overhead, что по сути означает перегрузку. Странно, что термин не понятен, он весьма древний. При некоторых действиях пользователя, которые невозможно запретить, возникает повышенное потребление ресурса процессора, которое снижает реактивность интерфейса до критической - приложением становится невозможно управлять. Это надо обнаруживать и снижать нагрузку на процессор. Изначально я начал тему, чтобы обсудить возможные варианты реализации этого обнаружения.

Это уже ближе к телу. Правда, мне не ясно, как считать paintEvent для всех элементов интерфейса, у меня их множество. Приложение может открыть более десятка окон на двух мониторах, а вообще их количество виртуально не ограничено - что пользователь захочет, то он и откроет. Какие плагины поставит, такие и будут окна открываться. В множестве случаев я не наследую классы этих окон. Впрочем, есть пара окон, которые обязательны, и которые наследуют QMainWindow. Достаточно ли будет отслеживать их паинты? Насколько я знаю, перерисовка в Qt производится только когда меняется содержимое окна, или его перекрытие, или по нему проходит курсор. Но курсор еще должен до него доехать... То есть, если курсор вне моих окон, и в них ничего не меняется - то о перегрузке-оверхеде узнать не получится. Нужен какой-то другой способ.

А она точно парализована? У её нити нет повышенного приоритета?

Не обязательно. Отрисовка замедлена, потому что сами функции отрисовки не получают достаточно времени. Они, как правило, по сравнению с очередью событий, более тайм-ёмкие.

То есть, надо пробовать...

up

Вернулся к этому вопросу. Попробовал для начала замерять время доставки обычных сигналов, и определять ситуацию, когда это время значительно увеличивается. Создал вариант, при котором интерфейс приложения вообще не откликается, и не перерисовывается. На 4-х ядерном процессоре загрузка всего 35-45%. То есть, компьютер работает, Веники живые, но само это приложение можно только прибить - на close главного окна оно реагирует, но больше ни на что. В этой ситуации даже не получается определить время доставки сигналов - они замерзают, никуда не доходят, любые попытки получить отладочную трассировку не имеют успеха.

Делал так - приемник соединен с передатчиком через QueuedConnection и крутит у себя нить, которая шлет сигналы, нагружающие процессор. Нить синхронизируется семафорами, этот код был ранее отлажен, и хорошо работает. Передатчик с такой же нитью посылает через очередь этому приемнику вместе с полезными данными (в тестовом режиме это были пары QString, то есть, довольно объемные данные) временной штамп (в миллисекундах в виде qint64), приемник получает штамп, и если разница текущего времени (QDateTime::currentMSecsSinceEpoch()) и штампа больше 1 секунды, то приемник глушит свою нить. При одной такой паре передатчик-приемник это работает. Но если создать 2-3 таких параллельно работающих соединения, то приемники просто перестают успевать обрабатывать сигналы. И явно передатчики тормозят и не успевают быстро посылать. При этом видно, что занятая память очень медленно растет - то есть, очереди наполняются, но не очищаются. Возможно, что сигнал об остановке таки был послан нити, но он тоже застрял.

Есть ли смысл проверять с помощью QEvent? Его механизм передачи существенно отличается от сигналов? Есть гарантия доставки QEvent при таком замерзании приложения, как описано? Можно ли доставлять QEvent с высоким приоритетом, чтобы обойти замерзшие очереди? Я не использовал формирование QEvent, обходился только обработкой сформированных системно.