C++, Qt, могут ли слоты вызываться не то количество раз, которое вызвались соединённые с ними сигналы?

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

нет. можно только очередь сделать.

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

Какую очередь? Зачем она, если «нет»?

Что за баг? Слот вызывается меньше, чем надо?

Разные ли потоки? Какой тип подключения сигнала к слоту (последний параметр в connect)?

ну эта, qt::queuedconnction или как оно там.

ну так ты бы начинал сразу с бага.

Функция-сигнал вызывается из разных потоков.

Не может)))

Нашёл баг. Qt безупречен, вызывает слоты в том же порядке и такое же количество, в каком ты вызываешь сигнал.

Баг был в том, что я 2 раза подряд вызывал сигнал, который нужно вызвать только 1 раз. Этот сигнал освобождал некий ресурс. При дефиците ресурсов (когда все они кому-то выданы) они нарасхват, первый освобождающийся сразу же кем-то начинал использоваться. Ошибочный повторный вызов освобождал ресурс снова (когда его уже кому-то выдали) и «движок» выдавал этот же ресурс кому-то повторно. Получалось, что два потока начинали использовать один ресурс. А ресурс серьёзный, в нём всякие состояния, счётчики. Race condition - два потока на один ресурс. Блокировок в ресурсе нет, т.к. by design «один ресурс - один поток».

но на всякий случай изучи что такое QMutex и QAtomicInt - вот я точно так же сейчас с Qt сижу и у меня куча потоков

раз число вызовов ведет к неправильной логике работы программы - считаю ты допустил ошибку проектирования

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

Число вызовов равное одному заложено в проект. Это не публичный метод, который все дёргают, это тонкая внутренняя механика.

никаких примитивов синхронизации, сетей и прочих пирогов с конями. Неправильно зависеть от библиотеки в том, в чём можно от неё не зависеть.

Ты сейчас это серьезно сказал? :)

Неправильно зависеть от библиотеки в том, в чём можно от неё не зависеть.

Ты делаешь мне смешно.

если ты хоть один класс из Qt используешь - ты уже зависишь от этой библиотеки на 100% и искусственно уменьшать степень этой зависимости не имеет смысла

либо ты делишь код на Qt и без-Qt часть - и это еще можно понять, но там где сигналы слоты не использовать QMutex - путь в никуда

это не разумное абстрагирование в данном случае, тебе уже написали

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

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

Хотя с выпиливаем некоторых вещей, таких как ls в работе с ftp в Qt5, работа заметно усложняется.

Я не очень понимаю, как вы измерили степень зависимости от библиотеки в процентах и почему у вас получилось их сто.

Ещё я не понял, как можно искусственно уменьшать степень зависимости и как тогда уменьшать степень зависимости «не искусственно»?

Вот захочу я отцепить гуй и сделать консольную версию, или сделать гуй на GTK - и мне чё, таскать за собой библиотеки Qt только потому, что я использовал примитивы синхронизации из него? У меня этих кросс-платформенных примитивов синхронизации в boost нет, можно подумать? )

«высокоуроневновой абстакции над платформозависимыми низкоуровневыми примитивами» - это смысл не только библиотеки Qt, не одна она такая умная.

ты лишь доказал мое утверждение

Новые сигнал-слоты в Qt5 тоже неплохи в плане производительности.

новые? а как они реализованы в Qt5? как-то иначе? где бы почитать...

https://qt-project.org/wiki/New_Signal_Slot_Syntax

Но коллбэки будут быстрей однозначно.

Какое именно?