Работа из QSerialPort из разных потоков

[Alechin]

> У меня только прохождение Ququed сигнала начала передачи заняло 20 мсек!
Что за прохождение? Чем замерял? Вызов слота при выдаче сигнала в однопоточном окружении не несет практически никаких накладных расходов (если используется Qt::AutoConnection)

использовать Qt::AutoConnection не получается - потоки разные. Только Queued.
а замерял просто qDebug()<<Time().currentTime()

[Пантер]

У меня сейчас сервис на Qt работает по сокетам с автомобильными трекерами, одновременно бывает подключено около 10К трекеров. Вся работа проводится в констексте одного потока и никакой просадки по производительности нет.

Этот сервис использует DeviceCommunicator?
Идея этого класса хорошая, спасибо за науку 

Нет, там более сложная архитектура. А это просто наколенный пример.

[Igors]

передача в порт 2-ух байтов "напрямую" с ожиданием их выдачи и получением ответа занимает 300 мксек. У меня
только прохождение Ququed сигнала начала передачи заняло 20 мсек! т.е. в 66 раз больше!

20 миллисекунд? Т.е. я смогу в секунду послать не более 50 сигналов queued? Такой рез-т - явный абсурд. Когда-то сам мерял - все там норм, не выдумывайте  

да, получается такое вот упрощение и повышения наглядности ПО.

Ну "преждевременной оптимизации" никто не отменял. Если хотите печатать из разных потоков - придется пойти на какие-то накладные расходы, и использование слот/сигналов - вариант очень приличный

почему вы все считаете что кто-то одновременно полезет? есть класс работы с принтеров. класс одни. все обращения к принтеру только через него. он сам разруливает кого пустить к принтеру а кого нет.

Ну и сосредоточьте всю работу с принтером в одном потоке, типа "всегда фоновый". Главный или какой-то другой поток захотел печатать - общается с "печатающим" через QueuedConnection

[Пантер]

> У меня только прохождение Ququed сигнала начала передачи заняло 20 мсек!
Что за прохождение? Чем замерял? Вызов слота при выдаче сигнала в однопоточном окружении не несет практически никаких накладных расходов (если используется Qt::AutoConnection)

использовать Qt::AutoConnection не получается - потоки разные. Только Queued.
а замерял просто qDebug()<<Time().currentTime()

Вот как раз из-за того, что потоки разные. Если делать один поток, то никакой просадки нет - делается прямой вызов.

[Alechin]

> У меня только прохождение Ququed сигнала начала передачи заняло 20 мсек!
Что за прохождение? Чем замерял? Вызов слота при выдаче сигнала в однопоточном окружении не несет практически никаких накладных расходов (если используется Qt::AutoConnection)

использовать Qt::AutoConnection не получается - потоки разные. Только Queued.
а замерял просто qDebug()<<Time().currentTime()

Вот как раз из-за того, что потоки разные. Если делать один поток, то никакой просадки нет - делается прямой вызов.

уточню: делать"не один поток" а делать все основном GUI потоке?

[Igors]

Вот как раз из-за того, что потоки разные. Если делать один поток, то никакой просадки нет - делается прямой вызов.

Та хоть и разные - до 20 миллисекунд там "дистанция огромного размера"

[Пантер]

Вот как раз из-за того, что потоки разные. Если делать один поток, то никакой просадки нет - делается прямой вызов.

Та хоть и разные - до 20 миллисекунд там "дистанция огромного размера"

Если были какие-то действия и ивентлуп не прокручивался, то хоть час может пройти.

[Пантер]

> уточню: делать"не один поток" а делать все основном GUI потоке?

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

[Alechin]

20 миллисекунд? Т.е. я смогу в секунду послать не более 50 сигналов queued? Такой рез-т - явный абсурд. Когда-то сам мерял - все там норм, не выдумывайте  

да, qDebug()<<QTime показыват именно такие цифры. Я так понимаю это очень похоже квант времени потока.

Ну и сосредоточьте всю работу с принтером в одном потоке, типа "всегда фоновый". Главный или какой-то другой поток захотел печатать - общается с "печатающим" через QueuedConnection

да уже так и сделано. Все работает. Удивила монструозность и тормознутость решения. Плюс непрозрачность (при взгляде со стороны), например дерганье своего собственного сигнала что бы вызвать свой собственный слот только потому что обычный port->write (по сути обычная запись файла!) не работает из чужого потока.
потому и возник вопрос "все ли я делаю так".

[Пантер]

20 миллисекунд? Т.е. я смогу в секунду послать не более 50 сигналов queued? Такой рез-т - явный абсурд. Когда-то сам мерял - все там норм, не выдумывайте   

да, qDebug()<<QTime показыват именно такие цифры. Я так понимаю это очень похоже квант времени потока.

Ну и сосредоточьте всю работу с принтером в одном потоке, типа "всегда фоновый". Главный или какой-то другой поток захотел печатать - общается с "печатающим" через QueuedConnection

да уже так и сделано. Все работает. Удивила монструозность и тормознутость решения. Плюс непрозрачность (при взгляде со стороны), например дерганье своего собственного сигнала что бы вызвать свой собственный слот только потому что обычный port->write (по сути обычная запись файла!) не работает из чужого потока.
потому и возник вопрос "все ли я делаю так".

Нет, ты делаешь не так.

[Igors]

да уже так и сделано. Все работает. Удивила монструозность и тормознутость решения. Плюс непрозрачность (при взгляде со стороны), например дерганье своего собственного сигнала что бы вызвать свой собственный слот только потому что обычный port->write (по сути обычная запись файла!) не работает из чужого потока.
потому и возник вопрос "все ли я делаю так".

Ну похоже что не так  Иначе не пришлось бы дергать свой же слот через queued

[Alechin]

я уже понял что нет так в смысле выноса в отдельный поток.
в таком случает (насчет предыдущего ответа с непрокручивание event_loop) - возникает боязнь что работоспособность системы будет зависеть от event-Loopа основного потока, что не есть хорошо. Работа в отдельном потоке не зависит от event_loopa других модулей программы. Виндовому WaitForMultipleEvent было все равно, даже если остальные потоки повисли - текущий всегда отрабатывал "мгновенно" свой функционал.
более того - для каждого потока (считай устройства, потому как работы с каждым устройством обычно шла в своем потоке) всегда отображалась статистика занятой памяти и времени работы потока, что позволяло легко отследить "взбесившиеся" устройства. Плюс для каждого потока отслеживалось что поток крутится, события приходят. если этого не происходило - поток автоматически перезапускался, в системный журнал делалась запись об этом..
В общем в выделении отдельного потока на каждое устройство были свои плюсы....
в принципе я все понял.......

[Alechin]

Ну похоже что не так  Иначе не пришлось бы дергать свой же слот через queued

в подходе с отдельным поток все так.
запись в порт из соседнего потока НЕ РАБОТАЕТ для QSerialPort.

[Igors]

в подходе с отдельным поток все так.
запись в порт из соседнего потока НЕ РАБОТАЕТ для QSerialPort.

"И это правильно". Запускаете "принтерный" поток (он и только он юзает QSerialPort), и пуляете в него сигналами - это все. Не нужно никаких доп EveтtLoop и.т.п.  Если у потока нет работы - он сам повиснет в своем событийном цикле. Ну и там флажков парочку накиньте - и все дела

[Пантер]

я уже понял что нет так в смысле выноса в отдельный поток.
в таком случает (насчет предыдущего ответа с непрокручивание event_loop) - возникает боязнь что работоспособность системы будет зависеть от event-Loopа основного потока, что не есть хорошо. Работа в отдельном потоке не зависит от event_loopa других модулей программы. Виндовому WaitForMultipleEvent было все равно, даже если остальные потолки повисли - текущий всегда отрабатывал "мгновенно" свой функционал.
в принципе я все понял.......

В большинстве случаев, все будет хорошо. Мне в сервисе пришлось выносить в отдельный поток сохранение данных на диск, когда я столкнулся с просадкой по производительности, ибо дисковый IO тормозил основной поток. Я создал класс, у которого есть метод на прием данных файла и поместил его в отдельный поток. Получилось так: класс принимает данне для файла и помещает их в очередь (собственно, вызов метода не имеет просадки), а дальше по ивентлупу потока происходит реальная запись данных в файл. В итоге, основной поток разгрузился и все опять заработало как часы.