Let's say we start a QTimer with a 100ms interval at t0.
Let's say first timeout occurs at t0+100ms. Fine.
Let's say that, due to huge CPU load and/or lots of events having to be handled by the event loop, second timeout occurs at t0+230ms.
Let's say CPU is back to normal load. Is their any chance that third timeout could occur at t0+300ms (QTimer object realising it was late and trying to correct that by resynchronizing itself), or will it most likely timeout at t0+330ms?
Per QTimer documentation :
All timer types may time out later than expected if the system is busy or unable to provide the requested accuracy. In such a case of timeout overrun, Qt will emit activated() only once, even if multiple timeouts have expired, and then will resume the original interval.
I'm not sure I understand this correctly but, apparently, it won't resynchronize itself and third timeout will occur at t0+330ms.
Related
In my application, it needs a timer to asynchronously launch a new UI screen when the timer expires.
The following code shows the desired semantics:
Timer t = Timer(Duration(seconds: myDuration), () {
askQuestion('How are you doing?'); });
// Maybe later, before the timer goes off...
t.cancel();
Using Timer, my implementation works sometimes, especially with small durations.
But when the duration is large, say 25, or 400 minutes, then my app would be killed and restarted, then the Timer is lost, the timeout will never happen.
My question is how I can make the Timer persistent surviving the restart of the app or reliable with some equivalent mechanism?
I may provide an ad hoc persistent solution by checking stored time value for the timer to expire at the (re)start of my program, and decide if I should relaunch the timer. But I'd like to learn if there is already a generic solution, as it's a general requirement for Future.delayed operation to survive program restart, otherwise, the use of Future.delayed is limited.
Otherwise, I might search for alternative solutions that provide persistence. I remember local notification might.
I think, you should have to start timer when application started, but you also need to write time when you should show screen to cache service/preferences/db. Then if your application killed and started again you will start timer with rest time(because you need every time start timer on start and you know how much is rest).
Imagine that you should show screen every 400 min. Okay, from now is DateTime.now().add(Duration(minutes:400)) and we can safely start timer from now to this time by (pseudo code) but idea should be clear
timeLeft = cachedDateTime - DateTime.now()
if(timeLeft<0){
show you page immediately and write to cache next time
}
else {
start timer with time left here
}
When application calls QTimer::start() is it started immediately or will be started after current event processed ? In other words, should I use single-shot timer with time correction in case of long-time processing in its timeout() slot ?
To answer with certainty would require inspecting platform-specific code within Qt. That's a good sign that this is not something you should be depending on. Moreover, QTimer doesn't promise much in terms of accuracy:
Timers will never time out earlier than the specified timeout value
and they are not guaranteed to time out at the exact value specified.
In many situations, they may time out late by a period of time that
depends on the accuracy of the system timers.
The accuracy of timers depends on the underlying operating system and
hardware. Most platforms support a resolution of 1 millisecond, though
the accuracy of the timer will not equal this resolution in many
real-world situations.
If Qt is unable to deliver the requested number of timer clicks, it
will silently discard some.
If you need to know precisely how much time has passed between timeout signals, use your QTimer in conjunction with a QElapsedTimer.
I have an asp.net page that runs certain algorithm and returns it's output. I was wondering what will happen and how to handle a case where the algorithm due to a bug goes into infinite loop. It will hog the cpu and other sessions will be served very slowly.
I would love to have a way to tell IIS, if processing Algo.aspx takes more than 5 seconds, kill it or something like that.
Thanks in advance
There is no such thing in IIS. What you can do instead is to perform the work in a background thread and measure the time it takes to complete this background task and simply kill the thread if the wait time is longer than expected.
You may take a look at the WaitHandle.WaitOne method which allows you to specify a timeout for waiting for a particular event to be signaled from a background thread for example.
Set the ScriptTimeout property. It will abort the page if the time is exceeded. It only works when the debugging property is set to true, though.
I have been involved in building a custum QGIS application in which live data is to be shown on the viewer of the application.
The IPC being used is unix message queues.
The data is to be refreshed at a specified interval say, 3 seconds.
Now the problem that i am facing is that the processing of the data which is to be shown is taking more than 3 seconds,so what i have done is that before the app starts to process data for the next update,the refresh QTimer is stopped and after the data is processed i again restart the QTimer.The app should work in such a way that after an update/refresh(during this refresh the app goes unresponsive) the user should get ample time to continue to work on the app apart from seeing the data being updated.I am able to get acceptable pauses for the user to work-- in one scenario.
But on different OS(RHEL 5.0 to RHEL 5.2) the situation is something different.The timer goes wild and continues to fire without giving any pauses b/w the successive updates thus going into an infinite loop.Handling this update data definitely takes longer than 3 sec,but for that very reason i have stopped-restarted the timer while processing..and the same logic works in one scenario while in other it doesnt.. The other fact that i have observed is that when this quick firing of the timer happens the time taken by the refreshing function to exit is very small abt 300ms so the start-stop of the timer that i have placed at the start-and-end of this function happens in that small time..so before the actual processing of the data finishes,there are 3-4 starts of the timer in queue waiting to be executed and thus the infinite looping problem gets worse from that point for every successive update.
The important thing to note here is that for the same code in one OS the refresh time is shown to be as around 4000ms(the actual processing time taken for the same amount of data) while for the other OS its 300ms.
Maybe this has something to do with newer libs on the updated OS..but I dont know how to debug it because i am not able to get any clues why its happening as such... maybe something related to pthreads has changed b/w the OSs??
So, my query is that is there any way that will assure that some processing in my app is timerised(and which is independent of the OS) without using QTimer as i think that QTimer is not a good option to achieve what i want??
What option can be there?? pthreads or Boost threads? which one would be better if i am to use threads as an alternate??But how can i make sure atleast a 3 second gap b/w successive updates no matter how long the update processing takes?
Kindly help.
Thanks.
If I was trying to get an acceptable, longer-term solution, I would investigate updating your display in a separate thread. In that thread, you could paint the display to an image, updating as often as you desire... although you might want to throttle the thread so it doesn't take all of the processing time available. Then in the UI thread, you could read that image and draw it to screen. That could improve your responsiveness to panning, since you could be displaying different parts of the image. You could update the image every 3 seconds based on a timer (just redraw from the source), or you could have the other thread emit a signal whenever the new data is completely refreshed.
if the maximum wait time is 10 ms can i use qwaitcondition in Qt's main thread?
Nothing stops you from using QWaitCondition in the main thread. If you are setting the wait time to 10ms, and it passes without unlocking you will probably not get the desired effects you want. The default is to wait indefinitely.
However, using a wait condition in the main thread will cause the GUI to become unresponsive while it waits. This is almost always undesired.