Очереди, самодельные сигналы

[Igors]

Что значит вряд ли.  Если посмотреть реализацию, то на каждой итерации, помимо обработки самих событий, происходит еще масса разных действий. И все это будет выполняться во всех таких нитках без всякой нужды.

Согласен, реализация через eventLoop скоростью не блещет. Напр. если каждая задача - обработка 1 точки имеджа, то все уйдет в eventLoop. Но такие скоростные задачи редки, напр. для обработки изображения построчно eventLoop.вполне годится.

[BRE]

Согласен, реализация через eventLoop скоростью не блещет. Напр. если каждая задача - обработка 1 точки имеджа, то все уйдет в eventLoop. Но такие скоростные задачи редки, напр. для обработки изображения построчно eventLoop.вполне годится.

Конечно, он вполне годиться для задач время выполнения которых значительно больше времени выполнения итерации eventloop. Просто потому, что последним временем можно пренебречь. 
Но для чего его вообще крутить? Если можно написать свое более эффективное решение, к тому же labview нужны хитрая очередь с приоритетами.

[Igors]

А в чем эта проблема?
Нитка останавливается на объекте QWaitCondition::wait, когда задание добавляется, то делаем QWaitCondition::wakeOne и одна из ниток просыпается и подхватывает задание.

Это "выглядит просто"   Когда вызывается QWaitCondition::wakeOne - нужно быть уверенным что кто-то уже спит на QWaitCondition::wait, а определить это может быть нелегко

[BRE]

Это "выглядит просто" 

Да нет, это и реализуется просто. 

Когда вызывается QWaitCondition::wakeOne - нужно быть уверенным что кто-то уже спит на QWaitCondition::wait, а определить это может быть нелегко

А для чего?

[Igors]

Когда вызывается QWaitCondition::wakeOne - нужно быть уверенным что кто-то уже спит на QWaitCondition::wait, а определить это может быть нелегко

А для чего?

Есть задание, данные для нитки-обработчика записаны, вызываем wakeOne. Однако обработчик еще занят предыдущим запросом и wakeOne не имеет эффекта. Обработка закончена, нитка честно ждет на wait, но поезд уже ушел.

Но для чего его вообще крутить? Если можно написать свое более эффективное решение, к тому же labview нужны хитрая очередь с приоритетами.

Очередь все равно формируется обработчиком, сценарий один и тот же, 1 виток цикла выглядит так:

- извлечь все пришедшие сигналы/события  из очереди (удобно из eventLoop)
- поместить все задания во внутреннюю очередь, там рассортировать как надо, удалить ненужные
- заняться первым заданием

Можно сделать и прерывание текущей задачи - ведь пришедшие сигналы доступны в любой момент. Зачем же городить свою внешнюю очередь вместо eventLoop ?

[BRE]

Есть задание, данные для нитки-обработчика записаны, вызываем wakeOne. Однако обработчик еще занят предыдущим запросом и wakeOne не имеет эффекта. Обработка закончена, нитка честно ждет на wait, но поезд уже ушел.

Ну это как написать. 

Очередь все равно формируется обработчиком, сценарий один и тот же, 1 виток цикла выглядит так:

- извлечь все пришедшие сигналы/события  из очереди (удобно из eventLoop)
- поместить все задания во внутреннюю очередь, там рассортировать как надо, удалить ненужные
- заняться первым заданием

Можно сделать и прерывание текущей задачи - ведь пришедшие сигналы доступны в любой момент. Зачем же городить свою внешнюю очередь вместо eventLoop ?

Вот это и называется городить огород. 
Кстати, а как могут быть доступны сигналы, если уже запущена задача (долгий цикл) и обработка событий в связи с этим приостановлена?

[Igors]

Кстати, а как могут быть доступны сигналы, если уже запущена задача (долгий цикл) и обработка событий в связи с этим приостановлена?

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

[labview]

Думаю нашёл что искал:

QWaitCondition::wait
QWaitCondition::wakeOne

Самое то!!! Спасибо, осталось с ними разобраться и всё должно получится, как я хотел.

Буду использовать QList + QWaitCondition вместо сигналов и слотов для коммникации между потоками.

Мне кажется Вы путаете синхронное с асинхронным   Сигнал всего лишь "посылает нитке задание". На посылающей стороне как правило нет выбора - задачи посылаются исполняющей нитке в порядке их поступления. Но исполнитель совсем не обязан следовать тому же порядку. В любой момент он может вызвать processEvents и посмотреть какие еще задачи пришли, прервать выполнение текущей задачи, установить свой порядок выполнения задач и.т.п.

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

[labview]

Скажите пожалуйста это правда что event loop неглавного потока выполняется в главном потоке, а только сам цикл, находящийся в Run() выполняется параллельно главному?

[BRE]

Скажите пожалуйста это правда что event loop неглавного потока выполняется в главном потоке, а только сам цикл, находящийся в Run() выполняется параллельно главному?

eventloop это и есть сам цикл и работает он в отдельном потоке.
Очередь сообщений тоже создается своя для каждого потока.

[off]Но вопрос зачОтный, читал несколько раз, много думал. [/off]

[labview]

Спасибо, не понял 

Event Loop один на все QThreads, но очередь ивентов для каждого разная?
Или у каждого Qthread свой Event Loop и естесственно своя очередь ивентов?

Если я нажимаю на кнопку на интерфейсе и вызываю слот, который был определён в одном из QThread, то функция в слоте выполняется в том же QThread или в другом, одним на все QThread?

[BRE]

Event Loop один на все QThreads, но очередь ивентов для каждого разная?
Или у каждого Qthread свой Event Loop и естесственно своя очередь ивентов?

Каждая нитка выполняет свой цикл и очередь сообщений у каждого своя.

Если я нажимаю на кнопку на интерфейсе и вызываю слот, который был определён в одном из QThread, то функция в слоте выполняется в том же QThread или в другом, одним на все QThread?

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

[labview]

Ага, теперь понял, большое спс 

[Igors]

Каждая нитка выполняет свой цикл и очередь сообщений у каждого своя.

Да, но нужно дополнить: любая нитка (кроме главной) должна вызвать exec(), иначе никакого eventLoop у нее не будет и никаких сообщений/сигналов она принять не сможет.

[lit-uriy]

labview, перефразирую то, что сказал Igors
event loop - цикл обработки событий - это метод exec().

любая нитка (кроме главной)

и главная тоже, если она не вызывает exec(), то и у неё не будет цикла обработки событий