Subject: Re: [boost] boost.timer library submission...
From: JohnQ (jqs_at_[hidden])
Date: 2009-06-05 03:11:06
>> Do you hold a mutex locked while invoking a callback?
yes, I'm holding a boost::unique_lock<boost::mutex>... as a result, the
callback method shouldn't do much. Mine only records the fact that the timer
fired and the data passed back and puts it on a queue for another of my app
threads to handle.
>>What mechanism do you use to suspend till it's time to fire a callback?
boost::condition_variable m_timed_cond.timed_wait(timer_lock, cur_timer)
>>What is the precision of your library? I mean if you instruct the
>>library to invoke your callback in so many ms usually your callback will
>>be invoked at bit later. The question is how long later? Or earlier?
Typically fires later than earlier... the tolerance window I've been using
is 5 ms - 10ms. The unit test included in the lib I uploaded to boost value
includes a test that puts 100 timers up and measures when they fire.
Occassionally out of that window. So far I've been running this on my mac
and there's a lot running on it typically, so I'm suspicious of my results
and think they could be better.
>>Does the precision degrade when you register lots of callbacks?
Not that I know of... I've put a couple of hundred thousand in there... so
far the time to rebalance the underlying map for insertion / deletion hasn't
shown up as an effect.
>>What's the smallest possible timeout the library lets to register a
>>callback with? How does the library handle small (e.g. 1 ms) timeout
Currently, millisecond resolution but totally happy to change it to reflect
the greatest accuracy the underlying system timer can achieve. I've been
testing this with a timing window (i.e., anything within, say, 10ms of the
original timer also gets called back). The timing window is configurable.
What platforms does the library work on?
Been compiling this on my mac. Will have it running on Centos shortly.
Haven't tried it at all on Win platform yet.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk