Set deadline_timer expired_at realtime clock 0 minute and repeat
Hi, How can I set deadline_timer expired at real clock absolute time at 0 minute, then repeat every minute? So it should expired at: 13:40:00, 13:41:00, 13:42:00 and so on? Thank you. Kind regards, - jupiter
On 26/08/2019 15:49, JH wrote:
How can I set deadline_timer expired at real clock absolute time at 0 minute, then repeat every minute? So it should expired at: 13:40:00, 13:41:00, 13:42:00 and so on?
Call timer.expires_at(when), where "when" is the ptime that you have calculated as the "next minute" time. Bear in mind that there may be some events (eg. PC sleep, processing overshoot) where you may need to skip some minutes, so you should generally calculate this time relative to when you actually finished the previous processing cycle (if this is a cyclic timer).
Thanks Gavin,
My problem is I have wired behavior for expiry at absolute time, I
have used deadline_timer for relative time for long time which works
well, but I could not get the absolute time work, here is what I set
up the timer to expire at 1minute 0 seconds:
boost::posix_time::ptime posixTime(clockNow,
boost::posix_time::hours(utcTime.time_of_day().hours()) +
boost::posix_time::minutes(utcTime.time_of_day().minutes() + 1));
expires_at(posixTime);
async_wait(boost::bind(&ClockTimer::Handler, this,
boost::asio::placeholders::error));
So the expiry time is 2019-Aug-26 07:09:00, but when the timer
expired, it called callback function 8 times consecutively, what could
I be wrong here?
Thank you.
- jupiter
On 8/26/19, Gavin Lambert via Boost
On 26/08/2019 15:49, JH wrote:
How can I set deadline_timer expired at real clock absolute time at 0 minute, then repeat every minute? So it should expired at: 13:40:00, 13:41:00, 13:42:00 and so on?
Call timer.expires_at(when), where "when" is the ptime that you have calculated as the "next minute" time.
Bear in mind that there may be some events (eg. PC sleep, processing overshoot) where you may need to skip some minutes, so you should generally calculate this time relative to when you actually finished the previous processing cycle (if this is a cyclic timer).
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 26/08/2019 19:17, JH wrote:
My problem is I have wired behavior for expiry at absolute time, I have used deadline_timer for relative time for long time which works well, but I could not get the absolute time work, here is what I set up the timer to expire at 1minute 0 seconds:
boost::posix_time::ptime posixTime(clockNow, boost::posix_time::hours(utcTime.time_of_day().hours()) + boost::posix_time::minutes(utcTime.time_of_day().minutes() + 1));
expires_at(posixTime);
async_wait(boost::bind(&ClockTimer::Handler, this, boost::asio::placeholders::error));
So the expiry time is 2019-Aug-26 07:09:00, but when the timer expired, it called callback function 8 times consecutively, what could I be wrong here?
Are you calling async_wait more than once? Each call to async_wait will queue up one callback when the timer expires. They will "stack up" if you call it more than once. Calling expires_at will cancel all previous async_wait calls (except in some borderline cases when the timer was concurrently expiring), but the callback function will still be called (with the operation_aborted code).
On 8/26/19, Gavin Lambert via Boost
On 26/08/2019 19:17, JH wrote:
My problem is I have wired behavior for expiry at absolute time, I have used deadline_timer for relative time for long time which works well, but I could not get the absolute time work, here is what I set up the timer to expire at 1minute 0 seconds:
boost::posix_time::ptime posixTime(clockNow, boost::posix_time::hours(utcTime.time_of_day().hours()) + boost::posix_time::minutes(utcTime.time_of_day().minutes() + 1));
expires_at(posixTime);
async_wait(boost::bind(&ClockTimer::Handler, this, boost::asio::placeholders::error));
So the expiry time is 2019-Aug-26 07:09:00, but when the timer expired, it called callback function 8 times consecutively, what could I be wrong here?
Are you calling async_wait more than once?
Nope, a function wrapped the pair of expires_at and async_wait for absolute time or expires_from_now async_wait for relative time.
Each call to async_wait will queue up one callback when the timer expires. They will "stack up" if you call it more than once.
Calling expires_at will cancel all previous async_wait calls (except in some borderline cases when the timer was concurrently expiring), but the callback function will still be called (with the operation_aborted code).
On 27/08/2019 02:05, JH wrote:
Nope, a function wrapped the pair of expires_at and async_wait for absolute time or expires_from_now async_wait for relative time.
Well, the underlying expiration mechanism is the same for both -- in fact expires_from_now is implemented by calling expires_at internally. Are you sure you're calculating the correct ptime for expires_at? It may perhaps help to use expires_from_now(x) to set an expiration and then call expires_at() to read the absolute expiration time that this set, and compare it with what you had calculated. Or conversely to call expires_at(x) and then read the relative time with expires_from_now() to see if that is as expected.
Thanks Gavin,
On 8/27/19, Gavin Lambert via Boost
On 27/08/2019 02:05, JH wrote:
Nope, a function wrapped the pair of expires_at and async_wait for absolute time or expires_from_now async_wait for relative time.
Well, the underlying expiration mechanism is the same for both -- in fact expires_from_now is implemented by calling expires_at internally.
Are you sure you're calculating the correct ptime for expires_at?
It may perhaps help to use expires_from_now(x) to set an expiration and then call expires_at() to read the absolute expiration time that this set, and compare it with what you had calculated.
Or conversely to call expires_at(x) and then read the relative time with expires_from_now() to see if that is as expected.
The expires_at(x) works at the first call, to workaround, I did exactly as you suggested to do the rest of calls using expires_from_now() for the time being, I do want to know why the second call of expires_at had that kind of problem, will do further debug. Thank you very much. - jupiter
On 27/08/2019 18:34, JH wrote:
It may perhaps help to use expires_from_now(x) to set an expiration and then call expires_at() to read the absolute expiration time that this set, and compare it with what you had calculated.
Or conversely to call expires_at(x) and then read the relative time with expires_from_now() to see if that is as expected.
The expires_at(x) works at the first call, to workaround, I did exactly as you suggested to do the rest of calls using expires_from_now() for the time being, I do want to know why the second call of expires_at had that kind of problem, will do further debug.
That's not quite what I said; I was just suggesting things that could be interesting to log for diagnostic purposes.
participants (2)
-
Gavin Lambert -
JH