QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?

Pl45m4

@mbruel said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

what is the waitFor you are talking about?

You did not mention what device you are using. A network device or do you have a serial port connection?

In case of the latter there are nice examples which illustrate both approaches:

https://doc.qt.io/qt-6/qtserialport-terminal-example.html

can we be awaken by a signal without a QWaitCondition ?

AFAIK you don't need QWaitCondition when using the QIODevice async API.

mbruel

You did not mention what device you are using. A network device or do you have a serial port connection?

I'm using a serial port.

In case of the latter there are nice examples which illustrate both approaches:

I've seen the examples and in general I'm used to the async approach for sockets.

AFAIK you don't need QWaitCondition when using the QIODevice async API.

So how would you do? I'm developing a lib that should reply to request from the main program and at the same time transfer the request on the serial port, and once the response is received on the serial port I should signal, and wake up my main method... I don't see how to do it without a thread and a QWaitCondition.... (if using async approach and not using active waiting (while loop with a sleep...)

artwaw

@mbruel said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

can we be awaken by a signal without a QWaitCondition ?

That's why we have readyRead() signal. You don't need (and should not even consider without a very valid reason) blocking approach.

You simply connect your slot to any of the ready...() signals and then proceed.

Now, depending if you're dealing with a serial port or network things might go different to some extent, so please read the available documentation very carefully.

(I am updating before posting since new answer arrived)

@mbruel said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

So how would you do?

Like above. Connect to the signal and process the data available at the moment.

mbruel

@artwaw I think you didn't get my usecase. I want to deliver a blocking service to the main app. So I've to wait. I don't want an active waiting loop. That is why the other only solution I see is to use a QWaitCondition
Do I miss something?

jsulm

@mbruel If you want blocking behavior then use the blocking API (like waitFor* methods). Why do you need QWaitCondition?

mbruel

@jsulm that's my question for performance question AND debugging: use the async architecture for I/O (so I'm sure I'm not loosing any frames) but do a blocking service. So how? the only way I see would be to put the I/O in a thread and use a QWaitCondition.
I'm wondering what do you think I can gain doing that? if this is "common" or not...

jsulm

@mbruel I don't understand the problem. Why would you lose frames?

mbruel

@mbruel I don't understand the problem. Why would you lose frames?

I want to make sure and test also the perf. I've some synchronization issues during my testing. probably due to the state machine but I'm looking all the directions. One would be to be async to be sure no frame ismissed cause we're in a wrong state.

Is it not more performant to use a QWaitCondition lock in the main thread instead of an active wait?... (embedded device, the less resources the better)

JonB

@mbruel
Don't know what you are saying about losing frames of what it has to do with sync vs async, but let's leave that.

What is your "active wait"? What makes you think calling waitForReadyRead() is any more "active waiting" than your own QWaitCondition? If you really want to know what the former does you can look at the source, but I doubt there is anything "active" about the waiting which differs from, say, QWaitCondition. You can always run with waitForReadyRead() and examine CPU activity during it to verify.

Christian Ehrlicher

Tbh I don't understand what QWaitCondition has to do with all this here and how this should in any way work with a QIODevice...

Creating problems without any needs or evidence that it does not work as written in the documentation...

mbruel

@Christian-Ehrlicher said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

Tbh I don't understand what QWaitCondition has to do with all this here and how this should in any way work with a QIODevice...

well the reason is simple: thread the I/O to make sure we don't miss frames...
Does it not make sense?

mbruel

@JonB said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

Don't know what you are saying about losing frames of what it has to do with sync vs async, but let's leave that.

good idea :)

What is your "active wait"? What makes you think calling waitForReadyRead() is any more "active waiting" than your own QWaitCondition? If you really want to know what the former does you can look at the source, but I doubt there is anything "active" about the waiting which differs from, say, QWaitCondition. You can always run with waitForReadyRead() and examine CPU activity during it to verify.

active wait to me is while(1) or for(;;) using a sleep like the implementation of waitForReadyRead.
I suppose it is more CPU consuming than a QWaitCondition lock on a Mutex where the thread has nothing to do if locked. Am I wrong?

jsulm

@mbruel said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

I suppose it is more CPU consuming than a QWaitCondition

Did you observe high CPU usage when using waitForReadyRead, or do you just assume it consumes a lot of CPU?
waitForReadyRead does not use a lot of CPU, so don't know what you're trying to optimize here...

mbruel

@jsulm
the main reason is to make sure I can trace all received frame (even if not in a good state in the main thread).
in term of architecture, I find it safer. you don't agree?

Pl45m4

@mbruel said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

active wait to me is while(1) or for(;;) using a sleep like the implementation of waitForReadyRead.

while(1) alone will utilize 100% of the available resources for this process/thread and runs as fast as possible.
However putting waitForReadyRead with or without timeout in, should avoid that, since it doesn't cycle in idle like a madman anymore, but is waiting for the readyRead() call instead (see @jsulm 's comment above).

"Assuming" CPU or memory utilization is another thing. Most tools aren't very accurate about that, esp. when you run your own non-optimized code. Same with memory leaks.

I don't understand your struggles here... you are asking about sync/async and later you mention that you want a blocking approach in your library?
Also as it's clear now that you are using QSerialPort, there are lots of (good) examples out there (officially by Qt and by other users) on how to implement (non-)blocking serial communication.

Christian Ehrlicher

@mbruel said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

Does it not make sense

Absolutely not and we try to tell you this bit you don't care for whatever reason...

If you would really loose bytes (not frames BTW - it's a stream) then this would be a Qt bug.

artwaw

@mbruel said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

So I've to wait. I don't want an active waiting loop.

The way I dealt with it in the past (waiting for input from serial port device) was to connect to signal in usual, async way, then disable ui by means of calling setEnabled(false); on a group box or whatever top level widget you have and possibly display buttonless modal window with an information "waiting for data" or something, then re-enable that once data arrives.
You don't need (nor want to!) disable idle loop. You want to wait for the data while user can't interfere (assuming this time around I got your use case right?). If so, this is my way.

mbruel

@Pl45m4 said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

I don't understand your struggles here... you are asking about sync/async and later you mention that you want a blocking approach in your library?

Yes, the library I’m developing should provide blocking services.
The thing is it has a machine state. Some states are from waiting command from the User, others for writing/reading on the device through the serial port.
My debugging “issue” was how to make sure I don’t miss some frames when I’m on a state that is not supposed to listen. (and potentially stay locked)
Well if the app is complete and well designed it shouldn’t happen. During the developing for testing it could be handy to make sure I don’t “miss frames”

@Christian-Ehrlicher said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

Absolutely not and we try to tell you this bit you don't care for whatever reason...

Well I read what you're all saying and take it into consideration. I will probably stick with the blocking approach then…

@Christian-Ehrlicher said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

If you would really loose bytes (not frames BTW - it's a stream) then this would be a Qt bug.

I'm talking about frames cause I've a filtering method to extract frames. Just states where I'm listening and others no... In my main thread. that's why the question of making the reading async in a thread came to my mind.

@artwaw said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:

You don't need (nor want to!) disable idle loop. You want to wait for the data while user can't interfere (assuming this time around I got your use case right?). If so, this is my way.

that's the way I would do too. But I'm doing a library for an embedded device. I can’t block anything. And I want to provide now a blocking service so the User (don’t have to do:

Send command to device
While ( Has it reply ?) do nothing
Get answer

Christian Ehrlicher

Last words here from me: no need for a separate thread here, use signals and slots. Everything else is over engineering for no reason.

J.Hilk

Even though it will hurt in the soul of many Qt developers you can of course use the sync function of QSerialPort in your project. But using the whole overhead of Qt to make a wrapper of serial port io access seems and not using Qt for the main program seams unreasonable. I would probably consider using something like libserial instead.

Even though if the task is explicitly to use Qt for the custom library, I would rather use/provide callback function access than use the blocking version. Just my humble opinion.