Re: [boost] Proposed boost timers library implementation concerns.

From: Glenn Schrader (gschrad_at_[hidden])
Date: 2007-07-20 12:57:34

Perhaps this is out-of-scope with respect to the design goals of this 
class but its useful to have timing that is synchronized across multiple 
systems. This is essential for doing things like latency testing as well 
as for many real-time applications. The typical approach is to use a GPS 
time signal and an interface board in each system. This results in 
system-to-system timing offsets of 10-20 uSec out-of-the-box. An a lot 
better with a bit of tuning. The interface to these timing boards is 
typically via a vendor supplied driver so it would be nice if there was 
a spot in the timing class where an adapter could be written to handle 
special cases like this.

Glenn Schrader - MIT Lincoln Lab

Michael Marcin wrote:
> Philippe Vaucher wrote:
>   
>> Cheers for your insights. Btw as you seem to work on non-posix and
>> non-windows system, can you tell me what timeing API there is on those
>> platforms ? Would it make sense to add a "others" namespace where non-posix
>> and non-win devices would be ?
>>
>>     
>
> I don't think it's necessary. If new platforms are supported such as 
> BREW or Symbian they probably deserve their own folders rather than 
> being lumped into other since they cannot use each other's timing 
> devices but they each have several devices.
>
> Personally all I would do is change the "timers_local_include.hpp" to 
> <boost/timers/local_include.hpp> (I've done this locally as well).
>
> Then I have a shadow copy of the boost directory in my include path 
> before the clean copy of boost.
>
> mini-boost/clean/boost
>
> then
>
> mini-boost/{platform}/boost
>
> This allows me to add files and folders and override behavior without 
> confusing my changes with the original code.
>
> If boost ever wants to officially support Windows Mobile, Symbian, BREW, 
> etc. then I'll have to rethink how to merge my changes into the mainline.
>
> P.S.
>
> What are the requirements on devices? Do they need to be copyable? Do 
> they need to start stopped? Do they need to be cheap to pass-by-value? etc.
>
> P.P.S.
>
> Interestingly a typo in my code led me to a timer that used another 
> timer as its device... funny that timer appears to satisfy the 
> requirements of the TimingDevice concept.
>
> Thanks,
>
> Michael Marcin
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
>