Очистка и прочее управление очередями

[Гурман]

Известно, что у Qt по необъяснимым причинам нет никакого управления очередями при соответствующих соединениях сигнал/слот. Очередь нельзя принудительно очистить, нельзя управлять её длиной, нельзя её "сливать" (игнорировать выход, если она никуда не подключена). Я искал объяснения, но ничего вменяемого не нашёл.

Есть желающие обсудить этот вопрос? Мне лично потребовалась необходимость очистки очереди и управления её длиной. Может стоит feature request написать? Или этот вопрос уже ранее поднимался (я с версии Qt 3.3 такого не помню, может прозевал)?

[Пантер]

Для чего тебе понадобилась такая возможность? Скорее всего, можно проблему решить по-другому.

[Гурман]

Для чего тебе понадобилась такая возможность? Скорее всего, можно проблему решить по-другому.

Для того, что в задаче нити общаются через очереди, а соединения между нитями могут динамически меняться, вплоть до отключения.  Надо иметь возможность очистки оторванной очереди и ограничения длины, чтобы нить при достижении очередью определенной длины останавливалась (как в случае QBlockingQueued). По-другому нормально - никак. А очереди в Qt - не объекты, во всяком случае, их структура снаружи не видна, их нельзя унаследовать и написать поверх них свой функционал.

[Old]

Пришло время использовать свои очереди.

[Пантер]

Да, свои очереди делай.

[Igors]

Известно, что у Qt по необъяснимым причинам нет никакого управления очередями при соответствующих соединениях сигнал/слот. Очередь нельзя принудительно очистить, нельзя управлять её длиной, нельзя её "сливать" (игнорировать выход, если она никуда не подключена). Я искал объяснения, но ничего вменяемого не нашёл.

Это не совсем так. Есть метод compressEvent (правда не документированный)

Есть желающие обсудить этот вопрос? Мне лично потребовалась необходимость очистки очереди и управления её длиной. Может стоит feature request написать? Или этот вопрос уже ранее поднимался (я с версии Qt 3.3 такого не помню, может прозевал)?

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

Я бы сначала поизучал compressEvent, сделал бы нужные операции с очередью как "тоже событие". Это просто предложение, оценивать типа "а вот это уже чепуха" не надо   Может и чепуха, может и нет.

[Bepec]

Механизм сигнал слот в Qt отлажен и подходит под 99% нужд, не заставляя даже задумываться о том, как оно работает. А у вас задача как раз в 1% попадает, в котором вам надо изменить механизм.
И если допустим они возьмутся за реализацию управления всем этим, то придётся весь механизм переписывать. Сейчас он прост и не вызывает затруднений именно тем, что хрен кто в него влезет

PS моё мнение - проще вам свою очередь написать.

[Гурман]

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

Причем 100% все нужные механизмы наверняка в очередях есть, иначе они бы вообще не работали. Просто наружу не вытащено.

Не вижу пока, как compressEvent может помочь хотя бы очистить очередь.

[Bepec]

Всё там есть, и очистка, и получение количества сигналов, и многое другое. Вот ток оно внутри. Коммерческую лицензию и флаг в руки.

[Igors]

Не вижу пока, как compressEvent может помочь хотя бы очистить очередь.

Да хотя бы так

Код

C++ (Qt)
bool MyApplication::compressEvent(QEvent *event, QObject *receiver, QPostEventList *postedEvents)
{
    if (event->type() == myClearAll) {
      postedEvents->clear();
      return true;
    }
    return QGuiApplication::compressEvent(event, receiver, postedEvents);
}

Только вряд ли это нужно/разумно делать

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

Категоричные суждения обычно поверхностны. Своя очередь практически неизбежна. Обычно она имеет высший приоритет (т.е. сначала выбираются все события из "своей" очереди, напр в eventFilter). Смешивать очереди не резон. Засылать события в свою очередь можно хоть напрямую, хоть с подскоком из того же compressEvent

Всё там есть, и очистка, и получение количества сигналов, и многое другое. Вот ток оно внутри. Коммерческую лицензию и флаг в руки.

Ну вот после таких ответов нервный ТС блокирует тему  

Суп на пароходе - прямо из Парижв! Открываешь кастрюльку - а там паааар..

[Гурман]

Увы, свою очередь делать не с руки, придётся весь механизм сигнал-слотов дублировать, потому что на него эта часть приложения полностью опирается. Общение между параллельными нитями сделано на сигналах и слотах, нити в плагинах, связывание сигналов и слотов автоматическое при загрузке плагинов, всё спроектировано, и в основном отлажено. А перепахивать приложение сейчас уже нет времени. На коммерческую лицензию сейчас денег никто не даст. А значит самый простой вариант - feature request, авось исполнится.

[Old]

А значит самый простой вариант - feature request, авось исполнится.

Еще можно свечу в церкви поставить, может помочь.

[Igors]

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

Чего это дублировать? Очереди "рабочих ниток" - что в них может быть кроме сигналов посланных из др ниток? По-моему аж ничего. Значит с ними можно напрямую. С главной ниткой так вряд ли прокатит, ну так если Вы собрались сливать/удалять - значит знаете что, т.е. интересующие события/получатели известны. Что мешает их выделить их отдельно? Выполнять их первыми - не проблема

[Гурман]

Очереди "рабочих ниток" - что в них может быть кроме сигналов посланных из др ниток? По-моему аж ничего.

Ну например, у меня с нитками через стандартные сигнал-слоты весь интерфейс общается. Которого не мало. Да и вообще вся главная нить. И пользователь может через этот интерфейс динамически подключать и отключать сигналы, даже во время выполнения нитей. Сейчас это всё без проблем работает на базовых сигналах. На своих - придется написать их фактически эквивалент, и еще не вполне понятно, как он должен взаимодействовать с базовыми сигналами. Именно с сигналами, это у меня основной механизм обмена. Всё приложение прошито соединениями, как мозг млекопитающего синапсами. События (Events) я в своем приложении вообще не создаю и не использую, и не собираюсь - только обрабатываю всякие интерфейсные, которые сам Qt посылает, по необходимости.

[Гурман]

Не, писать свои очереди я пока не буду. А вот запрос на фичу уже написал. 

Кстати, вспомнил - где-то еще в версии Qt 2.х, когда я с ним только знакомился, в его тусовке горячо обсуждался вопрос управления очередями. Противники говорили, что это нарушает принцип объектности и идеологию Qt, якобы дает возможность вмешательства в святыни. Сторонники говорили, что не будет нарушений, если очередью сможет управлять только тот, кто в неё посылает, этого будет достаточно. AFAIR тогда сказали, что это обсуждение будет продолжено в версии 3.х. Там, судя по всему, про это всё забыли. Но тогда еще не так горячо требовалась поддержка распараллеливания. Сейчас требуется. У меня в некоторые моменты времени работают 8 нитей одновременно, и это еще только середина разработки...