Boost logo

Boost :

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 (
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

Boost list run by bdawes at, gregod at, cpdaniel at, john at