Cannot read QSerialPort without event loop

Leonardo

The same documentation page for QSerialPort states that:

A blocking serial port does not require an event loop and typically leads to simpler code.

So I assumed that waitForReadyRead() might somehow handle this internally. If there's a QCoreApplication instance, maybe he could also call processEvents() inside his "for" to emulate a event loop.

mrjj

Oh ?!
So even
bool QIODevice::waitForReadyRead(int msecs)
says
"This function can operate without an event loop."

Its not in a way we except ?

aha_1980

@mrjj @Leonardo Oops, you may be right. Thinking again, my DLL may have used the signal driven approach - I cannot check this now.

@Hetsh: waitForReadyRead may be worth a try.

Hetsh

Thank you all for your input. Using waitForReadyRead did unfortunately not change anything. I think instantiating QCoreApplication as long as it does not exist will be the best short term solution for this.
Should this be reported as bug?

aha_1980

@Hetsh said in Cannot read QSerialPort without event loop:

Should this be reported as bug?

Yes, please do (and add a link here). That way we dig deeper into the issue.

Thanks.

kuzulis

There are no any bug. You need in QCoreApplication instance anyway. This even not an QtSerialPort issue.

aha_1980

@kuzulis @mrjj @Leonardo @Hetsh

I prepared a documentation update to clarify the status quo: https://codereview.qt-project.org/216669

aha_1980

Hi @Hetsh,

As @kuzulis correctly said (in the doc review), there are two examples that work without event loop:

http://doc.qt.io/qt-5/qtserialport-creadersync-example.html
http://doc.qt.io/qt-5/qtserialport-cwritersync-example.html

So you will need a QCoreApplication, but not an event loop.

Hetsh

@aha_1980 The example works, but it is using the waitFor methods in the "main" thread, which i cannot do.
@kuzulis I instantiated QCoreApplication both in the main thread and in the polling thread without any success.

I did a quick test on linux and it works without a QCoreApplication instance or event loop.

Back on windows I implemented the workaround from @aha_1980 by instantiating QCoreApplication in another thread and starting an event loop there. An important step is to move the port to the QCoreApplications thread. It won't work otherwise: https://pastebin.com/3sDcq3Hv

I filed a bug report.

Thank you all for your help :-)

kuzulis

Did creadersync example works for you?

Hetsh

@kuzulis yes it did

kuzulis

I have answered in your BR, and closed it as invalid, because you use QSP wrong.

PS: It works even w/o of QCoreApplication instrance and w/o of event loop. But needs to use the QCoreApplication instance to avoid some future/others problems (it suggested everywhere in Qt, AFAIK).

Hetsh

@kuzulis Thank you. It works perfectly now :-)

TLDR: My mistake was to not instantiate and open the QSerialPort in the thread i was reading from.

bast236

@kuzulis I am coding a Qt non-GUI DLL plugin that exports functions to do several things, including reading serial ports. These functions are called by an external .exe program (not using Qt, not coded by me) using a standardized API.

I have all sorts of bugs when using QSerialPort, as described in https://forum.qt.io/topic/137566/qserialport-with-no-gui-qobject-starttimer-timers-can-only-be-used-with-threads-started-with-qthread/12.

How to use QSerialPort without threads, without QCoreApplication, without event-loop, but just blocking IO calls?

kuzulis

As an option, you can create a separate thread in your DLL, e.g. QThread. Then, create the QSerialPort and then move it to that thread... Maybe it will help... An idea is that QSerialPort should get a QThread as a parent.

AFAIK, it is not simple to use the Qt classes in the separate DLL's. It belongs not only to QSerialPort, it belongs also to other QIODevice and other classes. e.g. that classess can use the QTimer internally, which does not work without of an event loop... So, it is hard... I have not ideas.