QObject timer events happening in reverse order
-
If I create a slew of timers, all with the same interval, and their scheduled time ends up being on the same tick of whatever clock they are scheduled against, they fire their events in the reverse order. Doesn't this seem Very Wrong? Does anyone know a way around this? I'm using 5.12 RC2 on Windows.
-
what is the way around are you looking for ? Are you using timerEvent(..) or QTimer ?.
-
If I create a slew of timers, all with the same interval, and their scheduled time ends up being on the same tick of whatever clock they are scheduled against, they fire their events in the reverse order. Doesn't this seem Very Wrong? Does anyone know a way around this? I'm using 5.12 RC2 on Windows.
-
I'm using
QObject::startTimer(), and defining my own virtualQOBJECT::timerEvent(). They're part of a simple system by which I can launch a function to be called in a certain amount of time. I'm trying to simulate a comm link that has a delay, so I want things to "get there" after a certain amount of time, but certainly in the same order that I sent them. The easiest way to implement this is to create a timer for each message I send, and kill the timer when it arrives. I catalog the function to be called as a numbered property of a common schedule object, indexed by the timer id, and delete the property after calling the function intimerEvent. It all works just peachy, except that it appears that when they are scheduled on the same timer tick, they are perversely pushed onto a stack rather than into a queue.Since they just released the official 5.12, I'm going to install that and see if there's any difference.
-
I'm using
QObject::startTimer(), and defining my own virtualQOBJECT::timerEvent(). They're part of a simple system by which I can launch a function to be called in a certain amount of time. I'm trying to simulate a comm link that has a delay, so I want things to "get there" after a certain amount of time, but certainly in the same order that I sent them. The easiest way to implement this is to create a timer for each message I send, and kill the timer when it arrives. I catalog the function to be called as a numbered property of a common schedule object, indexed by the timer id, and delete the property after calling the function intimerEvent. It all works just peachy, except that it appears that when they are scheduled on the same timer tick, they are perversely pushed onto a stack rather than into a queue.Since they just released the official 5.12, I'm going to install that and see if there's any difference.
An update: Unsurprisingly, 5.12 doesn't change anything.
I notice, though, that if I set the delay to zero, so that each timer merely fires as soon as the event loop is idle, they are all enqueued in the correct order, and the messages arrive in order. But of course, there is no programmable delay.
I wound up writing about a page of JS, along with a small C++ interface to the QObject timer, that uses a sparse array to associate a target time with a list of functions to call, and a single timer to signal an event on the earliest tick listed in the schedule. It works, but it is unwieldy and not nearly as efficient as just creating a timer per message. But it does let me control the order of things on each tick.
-
I'm using
QObject::startTimer(), and defining my own virtualQOBJECT::timerEvent(). They're part of a simple system by which I can launch a function to be called in a certain amount of time. I'm trying to simulate a comm link that has a delay, so I want things to "get there" after a certain amount of time, but certainly in the same order that I sent them. The easiest way to implement this is to create a timer for each message I send, and kill the timer when it arrives. I catalog the function to be called as a numbered property of a common schedule object, indexed by the timer id, and delete the property after calling the function intimerEvent. It all works just peachy, except that it appears that when they are scheduled on the same timer tick, they are perversely pushed onto a stack rather than into a queue.Since they just released the official 5.12, I'm going to install that and see if there's any difference.
Packets arriving out of order is a pretty accurate simulation of commlinks over the Internet. But if you want ordered serialization, you'll need to do that yourself. Put the messages in a queue, and pop the head whenever it's delivery time is less than the current time.
