QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?
-
@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"?
-
@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?
@JonB said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
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 a while(1) or for(;;), so could you point me to where this is in the Qt code for that method, please?
I linked the source here
@Pl45m4 said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
For a serial connection, it's there:
and I guess he did
@mbruel said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
ok it's an active while loop with a timer...
We suggested async, we suggested sync... if both ways do not appeal, we can't help any further... then @mbruel should try to figure out what he wants.
If debugging is the process of removing software bugs, then programming must be the process of putting them in.
~E. W. Dijkstra
-
@JonB said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
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 a while(1) or for(;;), so could you point me to where this is in the Qt code for that method, please?
I linked the source here
@Pl45m4 said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
For a serial connection, it's there:
and I guess he did
@mbruel said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
ok it's an active while loop with a timer...
We suggested async, we suggested sync... if both ways do not appeal, we can't help any further... then @mbruel should try to figure out what he wants.
-
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.
@J-Hilk said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
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.
The user of our lib is not using Qt, pure C++ and expect us to deliver the data in less than a timeout value or raise an exception and/or empty data with error code. I’d have prefer a callback! But there is some major processing behind on what I don’t have the hand.
@JonB said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
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?
I'm not there yet at all... I will check. my reflexion on the CPU usage was also for a loop even not infinite compared to a lock that can make switch context immediatly.
@artwaw said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
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"?
yes as fast as possible and with a timeout value... and raising an exception if something is wrong.
@JonB said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
I want to know whether the OP has looked at it to match their claims about it doing a busy/active wait.
OP?
-
@J-Hilk said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
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.
The user of our lib is not using Qt, pure C++ and expect us to deliver the data in less than a timeout value or raise an exception and/or empty data with error code. I’d have prefer a callback! But there is some major processing behind on what I don’t have the hand.
@JonB said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
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?
I'm not there yet at all... I will check. my reflexion on the CPU usage was also for a loop even not infinite compared to a lock that can make switch context immediatly.
@artwaw said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
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"?
yes as fast as possible and with a timeout value... and raising an exception if something is wrong.
@JonB said in QIODevice::waitForReadyRead question. comparison with async method and usage of waitcondition?:
I want to know whether the OP has looked at it to match their claims about it doing a busy/active wait.
OP?
