Qt + fifo или /dev/ttyS ?

Да что ж вы эту дрянь везде пропихнуть пытаетесь? Есть же обычные функции работы с устройствами и каналами: read, write, ioctl'ы там всякие...

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

О блин а мы-то не знали. А по делу можно, мне эту хрень на голом Qt реализовать надобы.

Для последовательный портов есть отдельная приблуда.

А у тебя один вызов read после прихода сигнала activated?

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

Есть ли нормальный вариант, кто подскажет?

А без приблуд?

Пробывал readAll не помогло.

На любом вызове аля read для объекта QFile на чьем дескрипторе произошло событие приема прога безнадежно подвисает в бесконечном ожидании.

Открывайте файл в неблокирующем режиме. Используйте select. Если так хотите пользоваться кутями - ковыряйтесь в манах всяких qserialport'ов.

Ну это очевидно не поможет, readAll же небось кусками читает, в результате данные на устройстве закончатся и read подвиснет. Я имею в виду системный вызов read.

>Да что ж вы эту дрянь везде пропихнуть пытаетесь? Есть же обычные функции работы с устройствами и каналами: read, write, ioctl'ы там всякие...

+1

нашел:

int buffSize = 0;
ioctl(fd, FIONREAD, (char *) &buffSize);

это чтоб узнать, сколько реально можно прочесть

Не хочет он по-человечески. Ему подавай все через жQt.

Теоретики - тупой вызов read на дескрипторе переданном сигналом activated(int) работает какой размер буфера ему не задавай, спрашивается какого такого рожна методы QIODevice/QFile висят???

ЗЫ: Можно поделу, ваш гон на то что Qt Г здесь не уместен, так как мне интересны способы решения конкретной задачи

через Ж это как раз select впиливать в проект полностью адаптированный под Qt и его eventloop через который (что самое важное) и нужно получать уведомления о приходе данных. Нахрена мне еще велик пределывать с селектом когда я априори не знаю что наступит раньше придут данные (если вообще придут) или запрос на отправку новой пачки данных от соседнего потока.

Знаем мы таких практиков, которые одну библиотеку под все нужды приспосабливают. Качай .net, чего уж тут.

прога безнадежно подвисает в бесконечном ожидании

O_NONBLOCK при открытии?

Тогда пользуйтесь рекомендованным выше qserialport. Или пишите свой, кроссплатформенный вариант, аналогичный этой библиотеке.

Неужели вы думаете, что в линуксовой версии qserialport работа с портами построена не через open/close, select/poll, read/write и ioctl?

Попробуй QFile::readData, он должен файл в nonblock-режим переводить

O_NONBLOCK при открытии?

Ну то есть это даже не вопрос, а утверждение. O_NONBLOCK нужен, и это в man select написано

       Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a sub-
       sequent read blocks.  This could for example happen when data has arrived but upon  examination  has  wrong
       checksum  and  is  discarded.   There  may  be other circumstances in which a file descriptor is spuriously
       reported as ready.  Thus it may be safer to use O_NONBLOCK on sockets that should not block.

Здесь написано про сокеты, но у меня и компорт подвисал, (я забыл ему указать NONBLOCK). Правда, это было очень редко (где-то раз в неделю непрерывной работы), но было. Если подвисает постоянно - что-то еще может быть не то.

Я открываю файл QFile получаю его дескриптор через QFile::handle() и на этом дескрипторе системный read работает в любых конфигурациях а методы исходного QFile от которого дескриптор отодрали висят.

Повеселило - оно же protected, меня к нему не пустят.

http://www.qtcentre.org/threads/20268-Non-blocking-stream-read ?

Повеселило - оно же protected, меня к нему не пустят.

Если сильно нужно - наследуй QIODevice и делай там что хочешь.

У меня так не работает!

ну можно унаследовать

хотя вызов read из QIODevice использует readData, так что он возможно виснет именно на ней

у тебя QIODevice::isSequentional что выдает? Если true, то файл должен переводиться в режим без блокировки

а вообще, посмотри отладчиком, на чем зависание происходит

>Да что ж вы эту дрянь везде пропихнуть пытаетесь?

Кроссплатформенность же.

Кроссплатформенность же.

Как угодно, но только не кутями или явой...

>Как угодно, но только не кутями или явой...

И как же это делать удобно и хорошо?

И как же это делать удобно и хорошо?

Если вы - программист, то и скажите. Я не программист. И уж кроссплатформенные приложения мне вообще не нужны. Я если и пишу что-либо, то только под POSIX-совместимые системы.