[Boost-users] [ASIO] Timer question
OvermindDL1
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
<pgqu...@elpauer.org> wrote:
> On Fri, Nov 20, 2009 at 8:05 AM, Koen Deforche <ko...@emweb.be> wrote:
>> Hey all,
>>
>> 2009/11/19 OvermindDL1 <overm...@gmail.com>:
>>>>> 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...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Pau Garcia i Quiles
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).
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Bjarne Laursen
about this in an earlier thread.
I created some code to fix it. See
https://svn.boost.org/trac/boost/ticket/3504
-Bjarne
Bjarne Laursen
<pgqu...@elpauer.org> wrote:
> 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).
Well it doesn't really work either. The timer expires imidiatly becourse
the time has passed. But if the thread doesn't do anything else but wait
for that it will not wakeup before the original time has passed. If it
wakes though; the timer gets recalculated.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Pau Garcia i Quiles
> Yes, I would say its broken. But it is a matter of defintion. I asked about
> this in an earlier thread.
> I created some code to fix it. See
> https://svn.boost.org/trac/boost/ticket/3504
I've fixed your code so that it work on all Unix platforms where
clock_gettime and CLOCK_MONOTONIC are available. The docs should also
note on Linux with glibc >= 2.11, linking with librt is required. It
might be required with glibc 2.10 too, but I have not tested.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Bjarne Laursen
<pgqu...@elpauer.org> wrote:
> I've fixed your code so that it work on all Unix platforms
Excelent, I though something like that would be needed, but I am new to
both Linux and Boost ;-)
-Bjarne
OvermindDL1
> On Mon, 23 Nov 2009 13:54:10 +0100, Pau Garcia i Quiles
> <pgqu...@elpauer.org> wrote:
>
>> I've fixed your code so that it work on all Unix platforms
>
> Excelent, I though something like that would be needed, but I am new to both
> Linux and Boost ;-)
I like that, that kind of timer makes more sense for relative times to
me. Now, who is going to commit it to trunk(/release) after verifying
it works and making some tests and documentation (a lot of work left)?