QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?
-
For a serial connection, it's there: https://codebrowser.dev/qt6/qtserialport/src/serialport/qserialport_unix.cpp.html#_ZN18QSerialPortPrivate16waitForReadyReadEi
ok it's an active while loop with a timer...
Then just don't call waitFor..., which will stop the current thread right there until the signal "unblocks" it.
what is the
waitForyou are talking about? can we be awaken by a signal without aQWaitCondition?@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.
-
@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? -
@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 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 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... -
@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
QWaitConditionlock in the main thread instead of an active wait?... (embedded device, the less resources the better) -
@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
QWaitConditionlock in the main thread instead of an active wait?... (embedded device, the less resources the better)@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 ownQWaitCondition? 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 withwaitForReadyRead()and examine CPU activity during it to verify. -
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...
Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
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...
@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
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 ownQWaitCondition? 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 withwaitForReadyRead()and examine CPU activity during it to verify.@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? -
@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?@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 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... -
@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?@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 puttingwaitForReadyReadwith or without timeout in, should avoid that, since it doesn't cycle in idle like a madman anymore, but is waiting for thereadyRead()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 usingQSerialPort, 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 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 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 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?@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. -
@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 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
-
Last words here from me: no need for a separate thread here, use signals and slots. Everything else is over engineering for no reason.
-
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.
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@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?@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.
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?Did you look at the implementation of
waitForReadyRead()as I suggested? You wouldn't have just said this without any evidence. You are saying it is awhile(1)orfor(;;), so could you point me to where this is in the Qt code for that method, please?I also suggested you try calling it and look at what the CPU utilization is, to see how it corresponds to what you are saying about its implementation. What did that reveal?
-
@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
@mbruel said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
But I'm doing a library for an embedded device. I can’t block anything. And I want to provide now a blocking service
Wait, so your task is defined as to "build a library in a way that would prevent the rest of the program from working until data arrives"?
