Блоки QextSerialPort при попытке чтения

Question

Я использую QextSerialPort в Windows, чтобы мое приложение Qt/C++ могло выполнять чтение и запись с / на последовательный порт.

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

Сначала я попытался подключить QextSerialPort::readyRead() Сигнал к слоту в моем основном классе, но я заметил, что приложение зависает.

Затем я попытался с помощью QextSerialPort::read(char *, uint64), который возвращает количество прочитанных байтов, и после этого я сделал еще одну неудачную попытку объединения QextSerialPort::bytesAvailable() а также QextSerialPort::read(char *, uint64) чтобы увидеть, поможет ли это моему приложению не блокировать.

Однако приложение всегда блокируется и должно быть уничтожено, поскольку оно не реагирует на события мыши или клавиатуры. Я утверждаю, что приложение зависает, потому что процедура чтения блокируется.

Есть ли способ выполнить неблокирующее чтение с помощью QextSerialPort?

Если нет, то какую библиотеку я должен использовать, чтобы иметь неблокирующие возможности чтения с последовательного порта в Windows?

ОБНОВЛЕНИЕ: я попытался использовать QextSerialPort::atEnd() проверить, есть ли байты для чтения вместо использования QextSerialPort::bytesAvailable() или же QextSerialPort::size() и это всегда возвращает ложь.

Answer 1

Чтения должны быть неблокирующими, если вы не установили режим запроса на опрос

    inline QueryMode queryMode() const { return _queryMode; }

    /*!
     * Set desired serial communication handling style. You may choose from polling
     * or event driven approach. This function does nothing when port is open; to
     * apply changes port must be reopened.
     *
     * In event driven approach read() and write() functions are acting
     * asynchronously. They return immediately and the operation is performed in
     * the background, so they doesn't freeze the calling thread.
     * To determine when operation is finished, QextSerialPort runs separate thread
     * and monitors serial port events. Whenever the event occurs, adequate signal
     * is emitted.
     *
     * When polling is set, read() and write() are acting synchronously. Signals are
     * not working in this mode and some functions may not be available. The advantage
     * of polling is that it generates less overhead due to lack of signals emissions
     * and it doesn't start separate thread to monitor events.
     *
     * Generally event driven approach is more capable and friendly, although some
     * applications may need as low overhead as possible and then polling comes.