Re: [Boost-users] [ASIO] Timer question

Subject: Re: [Boost-users] [ASIO] Timer question
From: Pau Garcia i Quiles (pgquiles_at_[hidden])
Date: 2009-11-21 08:24:35

Hello,

Answering myself (in a different mailing list, no less!), I'd say
deadline_timer is broken.

I've tested with the time_t_timer.cpp example from Asio itself. The
test is very easy:

- Say now it's 14:19:10
- Start time_t_timer
- Set time one hour back (to 13:19:10)
- Timers never expire (it doesn't matter if you do wait() or async_wait() )

Tested on Mac OS X 10.6.2. To make testing easier, I set the expiry
time to 20 seconds and used only one timer at a time (i. e. I
commented out the second half of the example the first time and had
only the wait() first, then did the opposite).

One intriguing issue is if instead of setting the time back one our,
you set the time forward one hour (15:19:10), the timer works. I don't
have time to research why this happens (I was expecting the test to
fail, too, as the point in time the timer is set to expire is never
reached exactly but just passed by).

On Sat, Nov 21, 2009 at 3:12 AM, OvermindDL1 <overminddl1_at_[hidden]> wrote:
> Greetings.
>
> I programming library that I use (WT) had a bug in their asynchronous
> timer handling, and although they fixed it, they are thinking of
> moving over to Boost::ASIO timers since they already use Boost::ASIO
> for the networking stack.  However, an interesting question was posed
> about how Boost::ASIO timers handle the time changing on the host
> computer (which is a possible scenario for this library due to its
> up-time requirements).  Below is the basic part of the thread in
> question.  Does anyone know the answer?  I attempted a quick look
> through the timer source, however I cannot really seem to tell since I
> know not the internals of ASIO nor the posix datetime library in
> Boost...
>
> On Fri, Nov 20, 2009 at 12:55 AM, Pau Garcia i Quiles
> <pgquiles_at_[hidden]> wrote:
>> On Fri, Nov 20, 2009 at 8:05 AM, Koen Deforche <koen_at_[hidden]> wrote:
>>> Hey all,
>>>
>>> 2009/11/19 OvermindDL1 <overminddl1_at_[hidden]>:
>>>>>> Speaking about WTimer, I think its implementation is wrong on Unix and
>>>>>> could be more precise on Windows (although I'm not sure more precision
>>>>>> is required; I've not checked if Wt::Time is used server-side).
>>>>>
>>>>> I haven't looked, but is there any reason that boost::asio::deadline_timer isn't being used to back WTimer?  I'm pretty sure this addresses all of the concerns listed below.  -sc
>>>>>
>>>>>
>>>>> http://www.boost.org/doc/libs/1_41_0/doc/html/boost_asio/reference/deadline_timer.html
>>>>
>>>> Much of Boost already handles a lot of things better, since boost is
>>>> linked in anyway then we should use them, they have already been well
>>>> debugged and optimized.
>>>
>>> That is very true. I guess a motivation at the time was to avoid the
>>> dependency on boost date_time for such a seemingly easy thing. But in
>>> the meantime, we are relying on boost date_time anyway, and it is
>>> clear that it is not that seemingly easy ?
>>
>> Actually, it is pretty easy. You've got 90% of the code there. Take a
>> look at the OSG file I said. Fixing this on Unix is straightforward,
>> fixing on Windows is easy too.
>>
>> Further, I think using boost date_time is not the right solution, as
>> it does not provide timers - i. e. you'll be basing the timer on the
>> clock time (hh:mm:ss) instead of processor ticks or some other entity
>> independent of clock time. If timers are based on hh:mm:ss -
>> hh':mm':ss' differences, they will fail when you change the computer
>> clock time.
>>
>> I have only looked slightly into the implementation of Asio timers and
>> they do not use gettimeofday but they don't use clock_gettime either,
>> therefore I wouldn't use them without carefully looking into the
>> implementation.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)