Re: [boost] boost::thread dependency on boost::chrono (windows implementation)

Subject: Re: [boost] boost::thread dependency on boost::chrono (windows implementation)
From: Pekka Seppänen (pekka.seppanen_at_[hidden])
Date: 2013-06-28 04:51:34

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