Here is how I use QTimer:
QTimer *timer = new QTimer(this);
connect(timer, SIGNAL(timeout()), this, SLOT(update()));
timer->setInterval(1000);
timer->start();
Program monitors update() function and prints the current time in it. Normally it works as expected, it prints time at every second, but when program starts to process other jobs, there would be some breaks like 5 to 8 secs.
Qt Documentation mentions about accuracy issues like 1 ms, obviously I have another problem. Any ideas ?
QTimer (and all event-base message deliveries) is not interrupt driven. That means you are not guaranteed you will receive the event right when it's sent. The accuracy describes how the event is triggered, not how it's delivered.
If you are not doing threaded process on long job, call QCoreApplication::processEvents() periodically during the long process to ensure your slot gets called.
Your other jobs run for several seconds, and there's no event processing during these. You'd need to thread the jobs in order to get the responsiveness you want.
Related
I am calling a function foo() continuously every second that checks the serial connection ,
Now my question is that what happens if one second passes and the function foo() is not completed the previous time it was called,will the previous function get executed first or will it get suspended etc
checkConnection =new QTimer(this);
checkConnection->start(1000);
connect(checkConnection, SIGNAL(timeout()), this, SLOT(foo()));
From the documentation at https://doc.qt.io/qt-5/qtimer.html:
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 timeout() only once, even if multiple timeouts have expired, and then will resume the original interval.
So it seems that only one timer event will exist in the queue at any one time.
That would mean your currently executing callback can take several seconds to complete and there would only be one queued in the meantime.
I'm building a simple game that shows a countdown to the user, starting at 1:00 and counting down to zero. As 0:00 is reached, I want to display a message like "time's up!".
I currently have a QTimer and a QTime object (QTime starting at 00:01:00)
QTimer *timer=new QTimer();
QTime time{0,1,0};
In the constructor I'm setting the timer to timeout every 1 second, and it's connected to an event that updates the countdown on screen, which is initially displaying the timer at 1:00:
connect(timer, SIGNAL(timeout()), this, SLOT(updateCountDown()));
timer->start(1000);
ui->countdown->setText(time.toString("m:ss"));
This is the slot being called every 1 second:
void MainWindow::updateCountDown(){
time=time.addSecs(-1);
ui->countDown->setText(time.toString("m:ss"));
}
Now I need to be able to call a new method whenever the QTime reaches 0:00. I'm not very keen on adding an if on the updateCountdown method to check if the QTime is at 0:00 every second. I also thought maybe I could add a second QTimer that times out at 1 minute, but I'm not sure if both QTimer objects will start at the exact same time so the 1 minute timeout will happen exactly when the QTime object is at 0:00.
So is there a way to add a second timeout to the same QTimer object (to timeout once every second to update the countdown on screen and then a second timeout after 1 minute to end the game? I suspect the answer will be "no", but in that case, what would be the best approach? (if none of my options are valid, is there a better way to do it?).
The answer to your first question is no -- QTimer supports a single timeout (or a single specified time-interval, if it's not running in single-shot mode).
The answer to your second question is -- the best approach is the simplest one that can possibly work. Use a single QTimer, and in your updateCountdown() method, include an if statement to do something different when the countdown finally reaches zero. (Btw you don't really need to use a QTime object to represent the countdown; you could just as easily use an int that starts at 60 and is decremented until it reaches 0)
Why is this better/simpler? You could use two QTimer objects instead, but then you have to worry about keeping them in sync -- perhaps that's not a big deal for now, but what happens when you want to add a "Pause" button to your game, or when you want to add a time-bonus that gives the player 10 extra seconds of play time? All of a sudden, your 60-second timer will no longer be doing the right thing, and it will be a pain to stop and restart it correctly in all cases.
If-statements are cheap, and easy to understand/control/debug; so you might as well use one.
When I create a QTimer object in Qt 5, and start it using the start() member function, is a separate thread created that keeps track of the time and calls the timeout() function at regular intervals?
For example,
QTimer *timer = new QTimer;
timer->start(10);
connect(timer,SIGNAL(timeout()),someObject,SLOT(someFunction()));
Here, how does the program know when timeout() occurs? I think it would have to run in a separate thread, as I don't see how a sequential program could keep track of the time and continue its execution simultaneously. However, I have been unable to find any information regarding this either in the Qt documentation or anywhere else to confirm this.
I have read the official documentation, and certain questions on StackOverflow such as this and this seem very related, but I could not get my answer through them.
Could anyone explain the mechanism through which a QTimer object works?
On searching further, I found that as per this answer by Bill, it is mentioned that
Events are delivered asynchronously by the OS, which is why it appears that there's something else going on. There is, but not in your program.
Does it mean that timeout() is handled by the OS? Is there some hardware that keeps track of the time and send interrupts at appropriate intervals? But if this is the case, as many timers can run simultaneously and independently, how can each timer be separately tracked?
What is the mechanism?
Thank you.
When I create a QTimer object in Qt 5, and start it using the start()
member function, is a separate thread created that keeps track of the
time and calls the timeout() function at regular intervals?
No; creating a separate thread would be expensive and it isn't necessary, so that isn't how QTimer is implemented.
Here, how does the program know when timeout() occurs?
The QTimer::start() method can call a system time function (e.g. gettimeofday() or similar) to find out (to within a few milliseconds) what the time was that start() was called. It can then add ten milliseconds (or whatever value you specified) to that time and now it has a record indicating when the timeout() signal is supposed to be emitted next.
So having that information, what does it then do to make sure that happens?
The key fact to know is that QTimer timeout-signal-emission only works if/when your Qt program is executing inside Qt's event loop. Just about every Qt program will have something like this, usually near the bottom its main() function:
QApplication app(argc, argv);
[...]
app.exec();
Note that in a typical application, almost all of the application's time will be spent inside that exec() call; that is to say, the app.exec() call will not return until it's time for the application to exit.
So what is going on inside that exec() call while your program is running? With a big complex library like Qt it's necessarily complicated, but it's not too much of a simplification to say that it's running an event loop that looks conceptually something like this:
while(1)
{
SleepUntilThereIsSomethingToDo(); // not a real function name!
DoTheThingsThatNeedDoingNow(); // this is also a name I made up
if (timeToQuit) break;
}
So when your app is idle, the process will be put to sleep inside the SleepUntilThereIsSomethingToDo() call, but as soon as an event arrives that needs handling (e.g. the user moves the mouse, or presses a key, or data arrives on a socket, or etc), SleepUntilThereIsSomethingToDo() will return and then the code to respond to that event will be executed, resulting in the appropriate action such as the widgets updating or the timeout() signal being called.
So how does SleepUntilThereIsSomethingToDo() know when it is time to wake up and return? This will vary greatly depending on what OS you are running on, since different OS's have different APIs for handling this sort of thing, but a classic UNIX-y way to implement such a function would be with the POSIX select() call:
int select(int nfds,
fd_set *readfds,
fd_set *writefds,
fd_set *exceptfds,
struct timeval *timeout);
Note that select() takes three different fd_set arguments, each of which can specify a number of file descriptors; by passing in the appropriate fd_set objects to those arguments you can cause select() to wake up the instant an I/O operations becomes possible on any one of a set of file descriptors you care to monitor, so that your program can then handle the I/O without delay. However, the interesting part for us is the final argument, which is a timeout-argument. In particular, you can pass in a struct timeval object here that says to select(): "If no I/O events have occurred after (this many) microseconds, then you should just give up and return anyway".
That turns out to be very useful, because by using that parameter, the SleepUntilThereIsSomethingToDo() function can do something like this (pseudocode):
void SleepUntilThereIsSomethingToDo()
{
struct timeval now = gettimeofday(); // get the current time
struct timeval nextQTimerTime = [...]; // time at which we want to emit a timeout() signal, as was calculated earlier inside QTimer::start()
struct timeval maxSleepTimeInterval = (nextQTimerTime-now);
select([...], &maxSleepTimeInterval); // sleep until the appointed time (or until I/O arrives, whichever comes first)
}
void DoTheThingsThatNeedDoingNow()
{
// Is it time to emit the timeout() signal yet?
struct timeval now = gettimeofday();
if (now >= nextQTimerTime) emit timeout();
[... do any other stuff that might need doing as well ...]
}
Hopefully that makes sense, and you can see how the event loop uses select()'s timeout argument to allow it to wake up and emit the timeout() signal at (approximately) the time that it had previously calculated when you called start().
Btw if the app has more than one QTimer active simultaneously, that's no problem; in that case, SleepUntilThereIsSomethingToDo() just needs to iterate over all of the active QTimers to find the one with the smallest next-timeout-time stamp, and use only that minimum timestamp for its calculation of the maximum time-interval that select() should be allowed to sleep for. Then after select() returns, DoTheThingsThatNeedDoingNow() also iterates over the active timers and emits a timeout signal only for those whose next-timeout-time stamp is not greater than the current time. The event-loop repeats (as quickly or as slowly as necessary) to give a semblance of multithreaded behavior without actually requiring multiple threads.
Looking at the documentation about timers and at the source code of QTimer and QObject we can see that the timer is running in the thread/event loop that is assigned to the object. From the doc:
For QTimer to work, you must have an event loop in your application; that is, you must call QCoreApplication::exec() somewhere. Timer events will be delivered only while the event loop is running.
In multithreaded applications, you can use QTimer in any thread that has an event loop. To start an event loop from a non-GUI thread, use QThread::exec(). Qt uses the timer's thread affinity to determine which thread will emit the timeout() signal. Because of this, you must start and stop the timer in its thread; it is not possible to start a timer from another thread.
Internally, QTimer simply uses the QObject::startTimer method to fire after a certain amount of time. This one itself somehow tells the thread it's running on to fire after the amount of time.
So your program is fine running continously and keeping track of the timers as long as you don't block your event queue. If you are worried of your timer being not 100% accurate try to move long-running callbacks out of the event queue in their own thread, or use a different event queue for the timers.
QTimer object registers itself into EventDispatcher (QAbstractEventDispatcher) which than takes care to send events of type QTimerEvent every time there is timeout for a particular registered QTimer. For example, on GNU/Linux there is a private implementation of QAbstractEventDispatcher called QEventDispatcherUNIXPrivate that makes calculations taking in consideration the platform api for the time. The QTimerEvent are sent from QEventDispatcherUNIXPrivate into the queue of the event loop of the same thread where QTimer object belongs, i.e. was created.
QEventDispatcherUNIXPrivate doesn't fire a QTimerEvent because of some OS system event or clock, but because it periodically checkes the timeout when processEvents is called by the thread event loop where QTimer lives too. Se here: https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qeventdispatcher_unix.cpp.html#_ZN27QEventDispatcherUNIXPrivateC1Ev
I have just started working with QT, and found the nice feature of QTTimer which triggers the slot at the interval of given period. Some point in time, I came across two situations.
1) if the timer is in the pending state, stopping timer have no issues that i won't even move to 'running state'.
2) If the timer is already running ( assume it is a bit long process task), then i found the stop will not terminate/stop 'running state'.
My Question:
At any given point of time, if stop is invoked, i should make sure it is stopped if it is already running.
Example:
connect(&myTimer,SIGNAL(timeout()), this, SLOT(missionStarted()));
When i Stop like this:
myTimer.stop() -> It actually stops the next firing the signal, but it does not stop running state of missionStarted().
What i thought of a solution ?
myTimer.stop();
while (myTimer.isActive()) {
}
qDebug()<<" I am guaranteed that missionStarted() is no more running, will not run anymore" ;
Is the solution is a way to go?. please guide me.
Does Qt Timer API stop and terminate the running slot?
No. The timer stop does not terminate running slot.
And how can I make it wait to get the timer slot execution completed?
There several ways to do so: with the signal back to the object that has the timer, for instance:
void MyWorkerClass::mySlot()
{
doTheJob();
emit signalIamDone();
}
And the the object that has the timer can acknowledge the slot stopped by connecting to that signalIamDone:
connect(&workerObj, SIGNAL(signalIamDone()), &managerObj, SLOT(workerJobDoneSlot()));
The actual slot:
void MyManagerClass::workerJobDoneSlot()
{
doSomethingOnJobFinished();
}
I would also try to use condition variable wait if you had a manager and worker thread but it seems like everything is running on one main UI thread.
And mind that usually the worker slot is getting called on the same main thread as your manager object runs unless your manager object is specifically running in the context of own thread. So, unless told otherwise about threads, you always have it waiting on the slot finishing you just need to know that the wait is over or doSomethingOnJobFinished called.
I have loop inside my main window code, that is simply changing the colour of some text-boxes on screen.
It is simply for(int i=0; i<200; i++), but I'd like to make every colour change visible to the user, so inside the loop I've tried to add sth like a 10ms pause, so every execution is visible on screen.
I used this:
QTimer t;
t.start(10);
QEventLoop loop;
connect(&t, SIGNAL(timeout()), &loop, SLOT(quit()));
loop.exec();
The problem is, that I'd like to have this 10ms pace constantly, so the whole operation will take about ~2 seconds. Unfortunately, it slows down gradually, so hard, that the last ~20 executions takes even about 1 second each
It looks rather decently when i<20~50, adding more makes it significantly slowing...
I thought about my not-really-brand-new PC, but it is really simple operation to be done, so I don't really think it is because of my slow pc.
I'm assume my approach is wrong
PS. During the execution, ram usage for my app is about ~21MB, and cpu about 20-30%
It is not good way to achieve something. QTimer is enough to this task. For example:
QTimer *t = new QTimer;//without loops and sleeping
connect(t, SIGNAL(timeout()), this, SLOT(someSlot()));
t->start(10);
Create someSlot and in this slot change color and do other tasks. To stop timer after 2 seconds, you can use counter instead of using system time.
void MainWindow::someSlot()
{
//do something
}
Also consider that 10 ms is very very fast, human eyes not able to catch so fast changing. Try to use longer value.