Это в Linux? Не знаю, я не выдергивал в 2.0 шнурок
Но по-моему это таже самая проблема что и раньше.


Скорее всего.

Как один из вариантов ее решения можно попробовать создать еще один QSocketNotifier, только для отлова IO exception, и назвать его типа exceptionNotifier. Плюс - добавить переменную-счетчик ошибок и, если exceptionNotifier срабатывает подряд, к примеру, 10 раз - то считаем, что шнурок выдернули и закрываем порт.
Но минус этого способа в том, что закрывать порт будет "нижний" уровень engine библиотеки, при этом, верхний уровень не узнает что порт был закрыт.

Другой вариант - это создать дополнительный класс типа SerialPortWatcher, который будет завязан на libudev или просто мониторить наличие файла в /dev. И если файл устройства исчезает из системы - то делать close(). В этом случае закрывать будет верхний уровень библиотеки.

В общем - нефик выдергивать шнурок.

Да, так и есть. :-) Я уже разобрался и все порешал для своих нужд.


На мой взгляд не очень изящный вариант... почему 10 раз, а не 20, как бы не совсем однозначный...


Именно так я и сделал, я переделал SerialDeviceEnumerator (из прежней версии qserialdevice) убрал все кроме мониторинга, исправил ошибку с нечтением сокета приводившую к 100% загрузке проца заюзал для этих целей. Спасибо за совет. Исправление в оригинальном (неурезанном serialdeviceenumerator) я сделаю позже и тогда пришлю merge request, ща просто времени нету.

В общем-то получилось все класно. Этот класс отслеживает на уровне udev появление исчезание устройств, посылает сигнал наверх где при помощи SerialPortInfo::availablePorts() опрашивается и отслеживается что за изменение произошло и закрываются/открываются порты. Не надо мутить никакие таймера думать как часто надо это делать... появилось устройсво - отработало. исчезло - отработало. все остальное время лишней митусни не выполняется.... :-)


Ну не надо быть таким категоричным... :-)
Задачи бывают разные, вот у меня устройство которое занимается диагностикой других приборов которые имеют на борту ftdi через которую осуществляется весь обмен более высокого уровня. Диагностируемый прибор может подключаться/отключаться в любой момент. Когда подключено идет периодический обмен данными, а потом прибор может быть спонтанно выдернут... Ну не будет пользователь делать "safe remove" как на компе для флешек (кстати часто и там не делают). Поэтому ситуация когда я подключил устройство, открыл порт, выдернул и прога подвисла - неприемлема.
А закрывать/открывать порт перед каждым периодическим обменом тоже не выход. Не предскажешь в какой момент произойдет отключение.
В любом случае спасибо за советы и быструю реакцию :-)

Да пожалуйста. Ты главное MR не забуть послать
Так сказать, на будущее.

Сообщение отредактировал kuzulis - 14.12.2011, 20:13

Сделал.

Ок. Спасибо. Я уже влил твой MR в Master ветку.
Доверяю не проверяя.

kuzulis, Я все забывал написать, у тебя в либе под линуксом не работает установка customBaudRate. Это касается и 0.4 версии и новой, вот сейчас только заметил в новой.
Визуально оно вроде как бы и работает т.е. делаешь setBaud и потом опрашиваешь и все вроде хорошо, показывает что установлена эта скорость, но реальный обмен на этой скорости не происходит.
Я попозже сделаю мерж реквест изменений которые решают эту проблему(в обе ветки). Но хотел бы чтобы ты все-таки просмотрел код и убедился что так действительно надо делать.
Во всяком случае я могу подтвердить что после моих изменений обмен на нестандартной скорости точно идет.

Кстати, shurilnik,

не хочешь ли стать контрибьютором (вкладчиком) этой библиотеки в Нокиа?

Если да (типа будешь учавствовать в её развитии, коммитить баги, фичи и т.п.),

то зарегистрируйся на их Jira баг-трекере: https://bugreports.qt.nokia.com/secure/Sign...33;default.jspa

И дай мне сюда затем полное имя твоей учетной записи.
Я его перешлю Нокиевцам и они для тебя создадут задачу на https://bugreports.qt.nokia.com
о том, чтобы ты принял их соглашение CLA.

т.е. они в данный момент собирают подписи всех участников, чтобы начать импорт QSerialDevice 2.0
в свой репозиторий и старта процесса интеграции в Qt.

Подробнее см. тему тут
там вроде самое начало обсуждения о принятии библиоттеки в Qt.
В общем, смотри эту ссылку на топик, а также последуюшие топики в той теме.

Суть в том, что если я сейчас приму твой MR для QSerialDevice 2.0 - то ты автоматически становишься
участником всей этой затеи с интеграцией.

Т.к. ты вливаешь свою часть кода в библиотеку, то необходимо и твое разрешение на начало
интеграции в Qt. Иначе Нокиевцы не начнут старт.

Так что: или ты регистрируешься в Jira и соглашаешься с CLA и я мержу твой реквест
или ты не регистрируешься и не соглашаешься, но тогда я твой реквест
переделываю "типа от себя" и добавляю от себя, т.е. о том, что он твой никто не узнает

Если ты согласен, то ОБЯЗАТЕЛЬНО начни с этого
т.е. делай как там написано.

Сообщение отредактировал kuzulis - 17.12.2011, 14:08

Эм, сложный вопрос


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


Правильно ли я понял что они при этом могут давать мне другие задачи по самой библиотеке ? Я просто боюсь что я не смогу оперативно на это дело реагировать...
Или как там все это происходит ?


Я как бы не возражаю и разрешаю


Я никогда не учавствовал в таких опернсорс проектах, как бы оно то и можно было бы, если меня не будут грузить задачами, а я сам если что-то найду - закомичу...
Как ты сам то посоветуешь сделать ?

Скорее всего. Я сам ХЗ как там оно.


Ну я то это понимаю. Но типа им нужно "официальное" согласие.


Да я тоже не участвовал.
Скорее всего я придержу твой MR до момента начала интеграции.
А там - посмотрим. В общем, разберемся.

Давай как пока подождем что они скажут.

Хорошо, пиши если что.