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

[Пантер]

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

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

Зачем отдельный поток? QSerialPort, как я понял, вполне себе заточен для работы в основном потоке, если использовать асинхронное общение.

[kuzulis]

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

Удивительно, правда? А с чего бы оно должно работать?
А документацию мы читаем, или пытаемся с наскоку
наделать потоков (понатыкать везде WaitFor, ну да, не резиновая),
а потом плачемся что оно тормозит и крешится?
Хотим вот так шлеп-шлеп и в продакшен?

PS: Интересно, удивлю, если скажу, что в Qt все классы QIODevice
не позволяют так делать - дергать методы из разныз потоков
(да и вообще все классы QObject по большому счету)!

[Alechin]

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

а никакх event_loop и нет.
вот как выглядит метод передачи:
void POS_Printer::Reset(quint _type)
{
   char req[3] = { 0x1b, 0x4a };  // ESC J
   req[2] = _type;
   port->write(req, 3);    <----------  не работает при вызове Reset() из другого потока.
}
приходится заводить сигнал signal_Reset();
подключать его через Queued к слоту Reset();
и вместо Reset() делать emit signal_Reset()
т.е. дергать самого себя за яйца.

[Alechin]

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

да - у меня у каждого устройства был свой журнал в памяти. Приходилось каждый журнал "закручивать" в своем потоке, что он не тормозил. А в каждом журнале был еще поток анализа файловой системы, так как журналы надо было чистить по времени устаревания. А сканирование файловой журнальной системы занимало десятки минут! (у нас в сутки система накапливает около 500 файлов объемом под 10ГБайт).

[Alechin]

Удивительно, правда? А с чего бы оно должно работать?

Удивительно! а с чего оно не должно работать? Сделать системный вызов записи в файл из другого потока невозможно? с каких это пор? Система не позволяет? или все-таки Qt не позволяет?

А документацию мы читаем, или пытаемся с наскоку
наделать потоков (понатыкать везде WaitFor, ну да, не резиновая),
а потом плачемся что оно тормозит и крешится?

а с чего поток должен тормозить на WaitFor? поток на WaitFor должен уйти в спячку и никаким образом не нагружать систему. Или в Qt WaitFor сделан через цикл опроса?!

PS: Интересно, удивлю, если скажу, что в Qt все классы QIODevice
не позволяют так делать - дергать методы из разныз потоков
(да и вообще все классы QObject по большому счету)!

это действительно интересно. Чем объясняется? дуростью разработчиков? система позволяет, а среда разработки не дает?

[Пантер]

Жесть. У меня сервис, который принимает данные от 20К трекеров (каждый шлет по несколько сообщений в секунду, сообщение - это n байт бинарных или текстовых данных), парсит данне, формирует xml и отсылает их в другую программу. Так же, отправляет команды на трекеры, логгирует работу, сохраняет xml и пр. И все, за исключением работы с диском, происходит в одном потоке. ЧЯДНТ?

[Пантер]

> это действительно интересно. Чем объясняется? дуростью разработчиков? система позволяет, а среда разработки не дает?

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

[Alechin]

Жесть. У меня сервис, который принимает данные от 20К трекеров (каждый шлет по несколько сообщений в секунду, сообщение - это n байт бинарных или текстовых данных), парсит данне, формирует xml и отсылает их в другую программу. Так же, отправляет команды на трекеры, логгирует работу, сохраняет xml и пр. И все, за исключением работы с диском, происходит в одном потоке. ЧЯДНТ?

еще раз повторю - у вас нет двух десятков железяк (8 LAN, 10 RS485, 128IO) которые могут отвалится, зависнуть, начать "штормить". При этом поток данных только от одного устройства около 100КБ в секунду. Данные надо распарсить, проанализировать, сбросить в журнал. Проверка оборудования проста. Подходим, выдергиваем что-нибудь или меняем местами кабели. Система должна в течение секунды восстановить работу и записать в системный журнал что с ней произошло. пользователя нет, более того - монитора обычно тоже нет. Пожаловаться некому, а продолжить работу надо. При этог не повлиять на десяток соседних устройств. При этом машинка - слабенький пром.комп с пентиумом.
Что приозойдет с одним потоком когда одно из устройств "заштормит"? или вы начнете сканировать файловую систему из 50 тысяч файлов? так вот скажу вам что сканирование такой файловой системы занимает около 3-ех часов.

[Пантер]

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

[Alechin]

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

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

[Alechin]

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

я выше указал две ситуации когда вы ничего поймаете у отвалившегося устройства.
а когда устройство "заштормит"? ваш один эвент луп справится?

[Пантер]

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

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

А зачем? Ты велосипедишь в кажом проекте? Возможно, у тебя ест на это время, у меня его нет, мне надо работу делать. Поэтому я с радостью возложил данные проблемы на Qt и использую предоставленную мне архитектуру. Code less, create more!

[Пантер]

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

я выше указал две ситуации когда вы ничего поймаете у отвалившегося устройства.
а когда устройство "заштормит"? ваш один эвент луп справится?

По поводу вытыкания патчкорда. Ну, заведи ты еще один экземпляр QTcpSocker и по таймеру подключай его/отключай и проверяй подключился ли он. Зачем для этого отдельный поток?

[Alechin]

я не "вилосипедю". мои системы управляют в реальном времени движением поездов (велком ту ПостЭЦ пассажирской станции москва-ленинградская и можно посмтреть в реальном времени как управляется осаживание поездов в тупики.

[Alechin]

По поводу вытыкания патчкорда. Ну, заведи ты еще один экземпляр QTcpSocker и по таймеру подключай его/отключай и проверяй подключился ли он. Зачем для этого отдельный поток?

а таймер в Qt какой? WM_TIMER или WaitableTimer?
вы уверены что на QTimer "можно положится"?