Russian Qt Forum
Март 29, 2024, 07:43 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 ... 4 5 [6] 7   Вниз
  Печать  
Автор Тема: Работа из QSerialPort из разных потоков  (Прочитано 42531 раз)
Пантер
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #75 : Март 24, 2017, 10:45 »

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

1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
Alechin
Гость
« Ответ #76 : Март 24, 2017, 10:51 »

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

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

Сообщений: 2812


Просмотр профиля
« Ответ #77 : Март 24, 2017, 10:53 »

Цитата: Alechin
Удивительно! а с чего оно не должно работать? Сделать системный вызов записи в файл из другого потока невозможно? с каких это пор? Система не позволяет? или все-таки 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)
и плодили бы там потоки.

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

ArchLinux x86_64 / Win10 64 bit
Пантер
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #78 : Март 24, 2017, 10:54 »

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

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

1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
kuzulis
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2812


Просмотр профиля
« Ответ #79 : Март 24, 2017, 11:01 »

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

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

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

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

ArchLinux x86_64 / Win10 64 bit
qate
Супер
******
Offline Offline

Сообщений: 1175


Просмотр профиля
« Ответ #80 : Март 24, 2017, 11:10 »

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

Именно сто одинаковые, все они QIODevice
И принцип работы с ними одинаков, событиями
Если нужны свои огороды - man termios
Записан
Alechin
Гость
« Ответ #81 : Март 24, 2017, 11:11 »

Жесть. У меня сервис, который принимает данные от 20К трекеров (каждый шлет по несколько сообщений в секунду, сообщение - это n байт бинарных или текстовых данных), парсит данне, формирует xml и отсылает их в другую программу. Так же, отправляет команды на трекеры, логгирует работу, сохраняет xml и пр. И все, за исключением работы с диском, происходит в одном потоке. ЧЯДНТ?
А стрессовое тестирование делали? если по одному сокету зарядить непрерывный поток очень больших сообщений, что будет с другими сокетами?
Записан
Alechin
Гость
« Ответ #82 : Март 24, 2017, 11:15 »

как закрыть тему?
Записан
qate
Супер
******
Offline Offline

Сообщений: 1175


Просмотр профиля
« Ответ #83 : Март 24, 2017, 11:16 »

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

обиделся ?
Записан
Пантер
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #84 : Март 24, 2017, 11:19 »

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

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

1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
Alechin
Гость
« Ответ #85 : Март 24, 2017, 11:20 »

обиделся ?
конечно нет! у меня уже не тот возраст чтобы обижаться Улыбающийся
просто все как-бы ясно.
просто ушли от темы. Я все понял про Qt. мне подход Qt понятен. я его понимаю.
я просто не уверен что перенос всего в один общий поток повысит надежность системы.
пусть все будет в одном потоке. И вдруг с порта например принтера поперли данные ("заштормило"). непрерывный поток.
апологеты "все в одном потоке" уверены что это не повлияет на работу, грубо, еще 20 подключенным принтеров?
а я сталкивался с такой ситуацией - неисправная радиостанция погнала непрерывный поток данных в систему.
Записан
Alechin
Гость
« Ответ #86 : Март 24, 2017, 11:22 »

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

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #87 : Март 24, 2017, 11:26 »

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

1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
Alechin
Гость
« Ответ #88 : Март 24, 2017, 11:47 »

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

Сообщений: 5876


Жаждущий знаний


Просмотр профиля WWW
« Ответ #89 : Март 24, 2017, 11:51 »

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

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

1. Qt - Qt Development Frameworks; QT - QuickTime
2. Не используйте в исходниках символы кириллицы!!!
3. Пользуйтесь тегом code при оформлении сообщений.
Страниц: 1 ... 4 5 [6] 7   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.062 секунд. Запросов: 23.