Создаю библиотеку для работы с последовательными портами. [УШЕЛ ИЗ ПРОЕКТА].

[kuzulis]

Хорошо, попробуй тогда (если есть время), проверить реализацию с новой концепцией отсюда:

https://codereview.qt-project.org/#change,32186

т.к. грядет полная переделка внутренней структуры.

[b-s-a]

Сделал, не помогло.

Ты пробовал делать moveToThread для порта?

[Phoenix]

Хорошо, попробуй тогда (если есть время), проверить реализацию с новой концепцией отсюда:

Вечером попробую.

Ты пробовал делать moveToThread для порта?

Для версии waitFor* пробовал. Всеравно падает. Еще в этой версии моей программы в потоке нет цикла обработки событий, но данные приходят. Такое ощущение, что события порта всегда обрабатываются главным потоком (даже если объект порта работает не в главном потоке). Или они все же обрабатываются в waitFor* хз.
Проверял даже вызовом thread() к какому потоку какой объект принадлежит. Проверял это для версии с  waitFor* и с сигналами/слотами.

Как я уже писал выше, в QSerialDevice 2.0 я вместо waitForBytesWritten применял msleep и работало. Что-то серьезное менялось при переходе от QSerialDevice  к QtSerialPort? Еще возможно что я ОС обновил, но не обратил внимание когда сегфолты начались. Но ОС работает стабильно, иногда несколько суток не выключаю.

[kuzulis]

Что-то серьезное менялось при переходе от QSerialDevice  к QtSerialPort?

нет

[Phoenix]

С новой библиотекой поток+waitFor* работает и не глючит. Проверял час, думаю на ночь оставить. Но при запуске выдает:

Код:

Warning: QObject: Cannot create children for a parent that is in a different thread.
(Parent is SerialPort(0x7fff19085ab8), parent's thread is QThread(0x22d3f00), current thread is port(0x7fff19085aa0)
Warning: QObject: Cannot create children for a parent that is in a different thread.
(Parent is SerialPort(0x7fff19085ab8), parent's thread is QThread(0x22d3f00), current thread is port(0x7fff19085aa0)

Видимо нужно SerialPort переместить в мой поток, сейчас он в главном потоке.
А вот с сигналами что-то не работает. Не генерируется сигнал readyRead(). Еще не разобрался.

[Bepec]

Помоему тут налицо просто неумение работы с потоками Но да пусть. Набирайся опыта.

[Phoenix]

Это потому что спросить не у кого. Нет знакомых программистов. Для меня это хобби.

[kuzulis]

А вот с сигналами что-то не работает. Не генерируется сигнал readyRead(). Еще не разобрался.

Да, это возможно, т.к. waitForXXX еще вообще не обкатывалось. Упор делался на использование сигналов.
Сейчас там в Gerrit страсти устаканятся и начнем обкатывать и внедрять эту новую внутреннюю структуру.

[Phoenix]

kuzulis, ты меня не понял, у меня waitForXXX работает, а сигналы нет.

[kuzulis]

Я тебя понял, но Не может такого быть. Вполне возможно что они не работают потому, что ты их используешь совместно с waitForXXX.

Если использовать чисто сигналы - то оно работает. Я ж проверял. 

[Phoenix]

У меня три варианта программы:
1. поток +  waitForXXX
2. сигналы/слоты
3. поток + сигналы/слоты
Первый работает, а остальные нет. Со вчерашнего дня я их не менял. Просто либу пересобрал. Возможно я где-то накосячил, сейчас разбираюь. Забыл сказать что у меня Linux х86-64. Может это тоже имеет значение.

[Phoenix]

Первый вариант работал 6 часов и не повис.

[navrocky]

Господа, а можно ли как-то приладить эту либу для чтения из пайпа (stdin)? Или может какая-нибудь внутренность подойдет?

[kuzulis]

Для пайпов возьми из Qt5 QPipeReader/Writer

[navrocky]

Для пайпов возьми из Qt5 QPipeReader/Writer

Что за зверь, почему гуголь о нём не знает? )

Впрочем, я уже обошёлся включением O_NONBLOCK на дескрипторе и использованием QSocketNotifier... Только под винду это работать не будет, но сейчас для меня это не критично.

Подожду релиза Qt5 тогда поубираю свои костыли.