Необходимость нового потока для очередно

[Igors]

to Igors:
Ну дай, ну дай мне похвастаться Я может быть ради этого момента на форуме регистрировался

Та на здоровье, это нормально 

PS и вообще мы на OPC переходим. Хоть и дороговат, но от головной боли по проектированию избавляет.

Не слышал ни о каком OPC, но не разделяю Вашего оптимизма, то палка о двух концах.Сегодня без проектирования - завтра без программистов вообще. А чего - девочки дешевле (+ имеют массу др. достоинств)

[Bepec]

Не в том смысле. OPC избавляет от головной боли распределённого доступа к объектам
Ну и унификацию позволяет произвести малой кровью. А программисты всё равно нужны (те, которые OPC изучат, ибо он в России почти не применяется)

[brucemax]

Я бы посоветовал, да незнаю задачи и устройств У меня к примеру охранка.Там скорость обработки важна + наивысший приоритет тревог. А у тебя я незнаю что

Мониторинг и частичное управление промышленными станциями (не могу сказать какими).  На каждой где-то по 4-5 датчиков. Но их опрашивает устройство на той стороне и уже оно формирует пакет и присылает его мне. Критичность по времени не сильно важна да и отправка как я сказал не часто. Теперь посоветуешь?   

[Bepec]

Время не важно. Значит что? Значит спокойно используем 1 поток на приём пакетов, 1 поток на обработку/сохранение результатов. Плюс основной поток на отображение информации.

Принимаем пакет (протокол твой соответственно должен гарантировать доставку), записываем в очередь на обработку, принимаем следующий.

Другой поток стоит на семафоре. Как только появляются данные, обрабатывает (хзкак, опять таки твоё дело) и отдаёт их на откуп модели и снова стоит ждёт.

Модель уже отображает данные и/или записывает в БД.

PS у тебя получается система сбора информации. Так же ты упоминал "частичное управление". Но это уже на твой откуп, подробностей не даёшь

[brucemax]

Спасибо!

...записываем в очередь на обработку..

В программном эквиваленте это например пустить сигнал,соединённый с объектом из потока обработки с указанием Qt::QueuedConnection?

[Bepec]

Как вариант да. Будет обычная очередь.

Хотя мне больше нравится обычное добавление в конец контейнера. Что по сути будет та же очередь

PS хотя у тебя требований к скорости нет, значит и сигналы пойдут (я им не доверяю )

 

[brucemax]

А корректно ли делать moveToThread после того как поток уже стартовал?  Просто в примерах  от Qt видел, что они сначала пихают объект в поток, а уже потом этот поток стартуют..

[Bepec]

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

[mutineer]

В доке противопоказаний нет

[Bepec]

Что-то типа SQLDatabase или SQLquery, не помню точно, будет требовать новое подключение к базе при переносе в другой поток. Т.е. фактически умирать

[brucemax]

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

Пока не знаю, как определить имеет ли класс ограничения, но у меня подключения возникают во время работы и чтобы кинуть сокет в обслуживающий поток  без данного действия не обойтись...  ммм..   Хотя обойтись..  сделав в том потоке объект, один из слотов которого будет клепать сокеты..  и эмитить ему сигнал из главного потока.   Или имея дело с сокетами (которые, надеюсь не имеют ограничений) не стоит париться и так сойдёт?

[Bepec]

ХЗ на всё. Сокеты бывают разные, черные, белые, красные, тисипишные и эскуэльные, удепешные и кутешные.

[brucemax]

ХЗ на всё. Сокеты бывают разные, черные, белые, красные, тисипишные и эскуэльные, удепешные и кутешные.

 

[Bepec]

А зачем вам сокеты в разных потоках?

[brucemax]

А зачем вам сокеты в разных потоках?

А где я написал, что они у меня в разных потоках?