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@elpauer.org> wrote:
On Fri, Nov 20, 2009 at 8:05 AM, Koen Deforche <koen@emweb.be> wrote:
Hey all,
2009/11/19 OvermindDL1 <overminddl1@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_...
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.
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@gmail.com> 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@elpauer.org> wrote:
On Fri, Nov 20, 2009 at 8:05 AM, Koen Deforche <koen@emweb.be> wrote:
Hey all,
2009/11/19 OvermindDL1 <overminddl1@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_...
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@lists.boost.org 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)
On Sat, 21 Nov 2009 14:24:35 +0100, Pau Garcia i Quiles <pgquiles@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/
participants (3)
-
Bjarne Laursen -
OvermindDL1 -
Pau Garcia i Quiles