On 28.6.2013 10:01, Christian Hägele wrote:
Unfortunately if it is not possible to switch to the old implementation of boost::thread(which doesn't depend on boost::chrono) we can't update to boost 1.54. That is a real blocker for us and I don't see a solution right now. Do I miss something? Are we the only ones who suffer from this problem on windows?
Ugh, is this a real show stopper? KB (http://support.microsoft.com/kb/274323) was last updated 2006 and the affected devices date way back, too (IDE/ISA stuff that is mostly legacy today). Don't really think it's smart to check OS API results for every system there is as clearly this is an isolated case. You'd have to maintain the affected PCI devices list, do string matching against the PCI IDs (= APIs provide a multi-line string with IDs and compatible IDs), etc. Get's pretty complicated eventually (do you require Boost.Regex, implement own multi-line string matching, use a naive strcmp solution that is error prone etc.) And then comes the funny part. What do you do when you encounter the leap (what counts as a leap)? Try again (how many times?), try again until things are synchronized again (what is the tolerance?), loop forever? A lot of work & maintenance just to support some old platforms that even MS doesn't deem to be worth fixing. I think this is the real problem: This should've been fixed at the OS level instead of forcing users to drop workaround for some specific HWs. Maybe you should gently try to tell your customers that in order to use newer versions of your software they should upgrade their HW & OS. It's not an easy job, I know, as I deal with the legacy stuff, too :( Imho the next best thing would be to check if Boost.Thread does any prev time < new time asserts (this is the *actual* steady-or-not problem, yes?). I.e. make sure that a leap doesn't crash anything. Sleeping a bit less than expected etc. shouldn't really matter anyway as you're not running a critical real time system. -- Pekka