A large number of Qtimers and guarantee of clicks.

I intend to have a fairly large number of Qtimers/ or QObject::startTimer(). By fairly large I mean around 2000. It is stated in the QTimer documentation that: http://doc.qt.io/qt-4.8/qtimer.html#details :

Quote:

---

If Qt is unable to deliver the requested number of timer clicks, it will silently discard some.

---

Does it mean although my objects(qobject inherited) have fairly large timeouts(around a second), but if significant number of them are to be set off at the same time, some clicks will be missed?
Or it does it mean for a particular QTimer, if the resolution is very close, some clicks will be missed.
My application have these timer clicks as a priority. To workaround this problem, I had a complicated logic to have a single timer manage all the clicks. I like to remove it. The application is not so time critical as in it is alright if the click is off by some ms, but if there is no click at all, there will be a problem.

And is there a limit of Qtimers. Documentation states that

Quote:

---

Some operating systems limit the number of timers that may be used; Qt tries to work around these limitations.

---

I intend to use the application on Windows and linux desktops. And how many timers can I safely scale the system to.

I think the logic of your application is not valid.
Let's take an example: 2000 clock with a period of 1 s which gives 2000 signals per second. Suppose that a signal service time is 5 ms which gives 10 seconds of time to support the 2000 event. During the 10 seconds You have received 20,000 signals and serviced only 2000. How do you imagine the proper operation of the program?

Quote:

---

Originally Posted by pkj

Does it mean although my objects(qobject inherited) have fairly large timeouts(around a second), but if significant number of them are to be set off at the same time, some clicks will be missed?

---

No, it means that if a timer has an interval of X miliseconds but the program is executing some function (related or unrelated to the timer) that takes more than X miliseconds (e.g. 2x X) then a timeout might be discarded.

That depends on your system. All depends on the accuracy of the system timers. The accuracy of timers depends on the underlying operating system and hardware. Are you getting any problem of missing clicks?

Quote:

---

I intend to use the application on Windows and linux desktops. And how many timers can I safely scale the system to

---

It totally depends on system processing power

Quote:

---

Originally Posted by Lesiok

I think the logic of your application is not valid.
Let's take an example: 2000 clock with a period of 1 s which gives 2000 signals per second. Suppose that a signal service time is 5 ms which gives 10 seconds of time to support the 2000 event. During the 10 seconds You have received 20,000 signals and serviced only 2000. How do you imagine the proper operation of the program?

---

That looks a very valid argument. I think I should stick to old idea of having a single timer managing all the timeouts. Most of 'em happen at around the same time anyway.

---

Added after 11 minutes:

Quote:

---

Originally Posted by wysota

No, it means that if a timer has an interval of X miliseconds but the program is executing some function (related or unrelated to the timer) that takes more than X miliseconds (e.g. 2x X) then a timeout might be discarded.

---

If I understand correctly then the event loop of application is a kind of a endless loop.As described in this document http://doc.qt.digia.com/qq/qq11-events.html. So it is kind of always in a function?? Do you mean if it takes 2x ms in a single function? Or if the event queue is not empty?

Yes, event loop is a endless loop but clocktimers signals are supported by all the other.
Let us know what you really have a problem to solve. Something we can advise you.

Quote:

---

Originally Posted by Lesiok

Yes, event loop is a endless loop but clocktimers signals are supported by all the other.
Let us know what you really have a problem to solve. Something we can advise you.

---

I have a large number of registers on external devices, each one of registers I represent by a QObject inherited object. Frequently I fetch up the data from these devices. If a register has a value satisfying a condition for a long enough time(lets call it delay), then I intend to emit a signal. The number of objects is intended to be scaled to be around 50000 max. Only some objects will have delays, but all may have it. Groups of these objects refresh their values by getting data from different sources.

Quote:

---

Originally Posted by pkj

If I understand correctly then the event loop of application is a kind of a endless loop.As described in this document http://doc.qt.digia.com/qq/qq11-events.html. So it is kind of always in a function?? Do you mean if it takes 2x ms in a single function? Or if the event queue is not empty?

---

The event loop is the thing running your timers (among doing a bunch of other stuff) :)

The way timers work is that there is a list of them in the event dispatcher with noted time left to timeout. When the event loop processes events, it updates this list reducing those times by the time difference to when it was called the last time. If that value for a specific timer reaches 0, the timer is fired, its time reset and put back into the list (unless it's a single shot timer). Thus the event loop doesn't keep any history of timer timeouts -- it can't determine how many times a timer should have fired, it's only fired once at a time.

Quote:

---

Originally Posted by wysota

The event loop is the thing running your timers (among doing a bunch of other stuff) :)

The way timers work is that there is a list of them in the event dispatcher with noted time left to timeout. When the event loop processes events, it updates this list reducing those times by the time difference to when it was called the last time. If that value for a specific timer reaches 0, the timer is fired, its time reset and put back into the list (unless it's a single shot timer). Thus the event loop doesn't keep any history of timer timeouts -- it can't determine how many times a timer should have fired, it's only fired once at a time.

---

If that is the implementation of QTimer, then it shouldn't matter whether I keep one Timer or 1000's of 'em. Essentially due to misinterpretation of the statement in doc, I had a timer with timeout of hcf of all timouts, and was juggling each timeout, to "reduce the load" !!

Quote:

---

Originally Posted by pkj

If that is the implementation of QTimer, then it shouldn't matter whether I keep one Timer or 1000's of 'em.

---

Not that much.

Quote:

---

I had a timer with timeout of hcf of all timouts, and was juggling each timeout, to "reduce the load" !!

---

It will reduce a load a bit. And you'll be sure that all functionality will be executed or none of it. With multiple timers (even for the same timeout) some of them might fire more than others.

Quote:

---

Originally Posted by pkj

I have a large number of registers on external devices, each one of registers I represent by a QObject inherited object. Frequently I fetch up the data from these devices. If a register has a value satisfying a condition for a long enough time(lets call it delay), then I intend to emit a signal. The number of objects is intended to be scaled to be around 50000 max. Only some objects will have delays, but all may have it. Groups of these objects refresh their values by getting data from different sources.

---

What is the frequency of reading a single register ?

Quote:

---

Originally Posted by Lesiok

What is the frequency of reading a single register ?

---

Frequency ranges from a second to a minute. Most of 'em are batched together. So I club 'em. So if you club all coming from same instrument(read port using x protocol), and use one single timer, the number of timers decrease.
But given the implementation of timers, separate timers for all will only save me some function over-heads at best. All instructions inside functions are best optimized by objects themselves by keeping the state up to date. But I am not sure.

I understand that the machine does not signal a readiness to read the data. I'd do it like this: for each read frequency separate thread that reads data from the registers in the loop. The thread runs one timer to read all records in order.