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

[Пантер]

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

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

Что там "под капотом" я не знаю, но доверять ему можно.

[Alechin]

Что там "под катом" я не знаю, но доверять ему можно.

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

Ладно, наш спор зашел в тупик. Я в общем все понял.
Qt - это подход быстрого написания несложного ПО не очень квалифицированным программистом (типа ВижлБеэйсика
для написания серьезного ПО Qt, конечно, тоже подходит, но придется поковыряться более чем основательно.

[kuzulis]

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

Дело в том, что QSP (как и большинство других I/O классов Qt) спроектирован для асинхронной работы с данными.

* QSP::write() просто добавит данные во внутренний буфер/очередь класса и взведет уведомитель (так называемый Write Notifier). Когда Write Notifier сработает, это значит что у-во готово принять новую порцию данных для передачи, и только в этом случае внутри класса будет произведен вызов ::write(fd, data, len) в который передадутся данные из буфера/очереди класса. После того, как данные были переданы, выстреливает сигнал bytesWritten().

* QSP::read() просто возвратит все доступные данные из внутреннего буфера/очереди класса, он не будет вызывать ::read(fd, data, len)! Вызов этой системной функции осуществляется внутри самого класса когда другой нотификатор (Read Notifier) уведомляет о том, что в у-во поступили данные и их можно вычитать. После того как данные были прочитаны, они добавляются во внутренний буфер/очередь класса и выстреливается сигнал readyRead().

И аналогично работают большинство классов I/O в Qt. Я не понимаю, что тут может быть не понятно? И в чем, собственно проблема..

PS:

* Так, а зачем вообще был выбран Вами Qt в таком случае? Писали бы на любимом борланде (в реинкарнации Lasarus для Linux)
и плодили бы там потоки.

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

[Пантер]

Что там "под катом" я не знаю, но доверять ему можно.

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

Ладно, наш спор зашел в тупик. Я в общем все понял.
Qt - это подход быстрого написания несложного ПО не очень квалифицированным программистом (типа ВижлБеэйсика
для написания серьезного ПО Qt, конечно, тоже подходит, но придется поковыряться более чем основательно.

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

[kuzulis]

Qt - это подход быстрого написания несложного ПО не очень квалифицированным программистом (типа ВижлБеэйсика Улыбающийся
для написания серьезного ПО Qt, конечно, тоже подходит, но придется поковыряться более чем основательно.

Или Вы тролль, или у меня монитор заплыл жирком.

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

Ок, я теперь понял почему поезда опаздывают! ПОЛНЫЙ ТУПИК! Патамучто софт пишут профи с 15-ти летним опытом на теплом ламповом билдере/дельфяшечках под WinXP. Излюбленный подход - насоздавать потоков (чем больше тем лучше) и понатыкать блокировочек.

[qate]

Сокеты и оборудование это несколько разные вещи.

Именно сто одинаковые, все они QIODevice
И принцип работы с ними одинаков, событиями
Если нужны свои огороды - man termios

[Alechin]

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

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

[Alechin]

как закрыть тему?

[qate]

как закрыть тему?

обиделся ?

[Пантер]

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

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

И пусть идет, главное, что я читаю и обрабатываю данные правильно.

[Alechin]

обиделся ?

конечно нет! у меня уже не тот возраст чтобы обижаться
просто все как-бы ясно.
просто ушли от темы. Я все понял про Qt. мне подход Qt понятен. я его понимаю.
я просто не уверен что перенос всего в один общий поток повысит надежность системы.
пусть все будет в одном потоке. И вдруг с порта например принтера поперли данные ("заштормило"). непрерывный поток.
апологеты "все в одном потоке" уверены что это не повлияет на работу, грубо, еще 20 подключенным принтеров?
а я сталкивался с такой ситуацией - неисправная радиостанция погнала непрерывный поток данных в систему.

[Alechin]

И пусть идет, главное, что я читаю и обрабатываю данные правильно.

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

[Пантер]

И пусть идет, главное, что я читаю и обрабатываю данные правильно.

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

Буду, если это нормальное поведение. А если ненормальное, просто закрою подключение и заново его открою. Это уже решение под конкретную ситуацию. Я сталкивался с проблемами с железом, когда получал видео с камеры и управлял ею. Вот только потоки не решили проблему. Пришлось разносить на разные процессы - основной процесс управлял камерой и запускал дополнительный процесс, который читал видео и передавал его основному через stdout. Тут для каждой железки может быть свой подход, но это не обязательное бездумное вынесение в отдельный поток.

[Alechin]

Тут для каждой железки может быть свой подход, но это не обязательное бездумное вынесение в отдельный поток.

ну а сможете перключить то? я наблюдал ситуацию 100% нагрузки из-за одного канала, не позволявшей, вернее позволявшей с ОЧЕНЬ большой задержкой что-то делать остальному оборудованию. Этоже с выносом в отдельный поток полностью решило проблему - 100% загруз одного потока никак не влиял на остальное оборудование - время отклика остальных осталось прежним. А у меня есть программно реализованный протокол радиоканала с временным разделением канала: так вот EmWin на довольно слабом железе обеспечиват окна радиобмена в потоке данных 50 мсек только благодаря тому что все разделено на потоки и никак не мешает друг-другу.
а почему вы так против потоков? сами потоки систему никак не нагружают но здорово позволяют отвязать разнородное по нагружанию системы оборудование друг от друга. А всякие бугалки про "разделение данных" и "синхронизацию" - не более чем пугалки. Что сложного в защите данных критическими секциями? И добавления к данным событий чтобы можно было будить любой поток, ждущий этого события?

[Пантер]

1. Переключение между потоками это затраты.
2. Мютексы это затраты
3. Усложнение архитектуры
4. Большая вероятность допуска ошибки, которую крайне тяжело будет вычленить.
Вот почему потоки "by default" это плохо.

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