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