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.