2015-10-19 8 views
1

Если я хочу записать данные на удаленную сторону и дождаться ответа, мне нужно как минимум waitForReadyRead. Но прежде чем позвонить, мне нужно вручную очистить очередь вывода, используя waitForBytesWritten, или Qt автоматически очищает очередь записи для меня? Я работаю синхронно (блокирование), и поэтому в этой функции я не могу использовать цикл событий или локальный цикл событий.QIODevice :: waitForReadyRead неявно очищает очередь вывода (waitForBytesWritten)?

При использовании std::cin мы можем быть уверены, что ранее записанные байты на std::cout были сброшены. Это аналогичная ситуация - применима ли она к сокетам Qt?

ответ

0

Если вы посмотрите на source code, будучи абстрактным базовым классом, QIODevice делает очень мало waitForReadyRead и это до реализации наследуемых классов:

bool QIODevice::waitForReadyRead(int msecs) 
{ 
    Q_UNUSED(msecs); 
    return false; 
} 

это относится к Qt розетками Aswell?

Как вы заявили, что вы работаете синхронно, я предполагаю, что вы выбрали это по причине, и известно, что в главном потоке, любой графический интерфейс присутствует замерзнет во время вызова waitForReadyRead. Обычно предпочтительным является асинхронное использование для QIODevice, а Qt - среда, управляемая событиями.

Однако Qt docs состояние:

некоторых подклассов QIODevice, такие как QTcpSocket и QProcess, являются асинхронными.

Поэтому, если ваш QIODevice является сокет, такой как QTcpSocket, то нет, вы не должны быть обязаны называть waitForBytesWritten при вызове waitForReadyRead.

В случае несинхронного устройства это потребуется.

+0

Хмм, я не понимаю вывода «Поэтому, если ваш QIODevice является сокетом, таким как QTcpSocket, то нет, вам не нужно будет вызывать waitForBytesWritten при вызове waitForReadyRead». Что предотвращает Qt от простого опроса или 'select'-ing дескриптора файла сокета для новых байтов и заполнения его очереди чтения? Почему асинхронность подразумевает, что мне нужно сбросить байты? –

+0

У меня создалось впечатление, что «асинхронный» в этом контексте означает, что вызов записи и чтения не имеет прямого доступа к устройству, а чтение и запись в буферы, которые только записываются или считываются при возврате цикла событий или при вызове одна из функций ожидания? –

+0

Возможно, я неправильно понял ваш вопрос и, пожалуйста, поправьте меня, если это так. Как бы то ни было, по асинхронному я понимаю, что он подразумевает, что он обрабатывается в отдельном потоке, поэтому вызов waitForReadyRead, который является блокирующим вызовом, часто в основном потоке, не будет блокировать процесс записи для устройства, такого как QTcpSocket. – TheDarkKnight

0

Я впоследствии спросил Тьяго Масиейру (сопровождающего QtCore) о предмете, и он ответил, что для QAbstractSocket оба waitForBytesWritten и waitForReadyRead будут писать ожидающие байты, которые сидели в буфере qt, ожидая передачи в ОС.

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

Следовательно, функции bytesWritten и readyRead wait обрабатывают как буфер чтения qt, так и qt. WaitForBytesWritten может даже излучать сигнал readyRead, чего я не ожидал. Поэтому вызов waitForBytesWritten по существу был избыточным и может быть удален.

 Смежные вопросы

  • Нет связанных вопросов^_^