Boost logo

Boost-Build :

Subject: Re: [Boost-build] [Boost-commit] svn:boost r79511 - trunk/tools/build/v2/engine
From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2012-07-15 11:24:04


>> Windows Boost Jam implementation now uses finer resolution than
>> 1 second when creating timestamps based on the current system
>> time. Since these are never (and should never be!) compared to
>> file system timestamps - this causes no conflicts with file
>> system timestamps still using 1 second resolution at best.
> If they're really disjoint like this, and your
> special struct is only useful for the current
> time, then why are you using it for file timestamps?

   I am actually trying to get the filestamps modeled using a finer
resolution than 1 second and the aforementioned change seemed like low
hanging fruit found along the way so I committed it separately.

   As to why both use-cases are modeled using the same type of objects -
the concept of holding a 'point in time' seemed the same whether you
want to track a point in time 'a file was last touched' or a point in
time 'an external process got started'.

   The main difference between the two is the source of the time
information. If you concurrently (A) get it from the file system and (B)
get it from the current time, there is no guarantee that the timestamps
will match. E.g. for (A) FAT file system tracks file modification times
with a 2 s resolution, and for (B) Windows GetSystemTimeAsFileTime() API
reports the current time with about 15 ms resolution, etc. This means
that you can get (A) < (B), (A) == (B) or (A) > (B) depending on how OS
provides the time source of that information independent of whether you
asked for (A) or for (B) first and there is no guarantee that if you got
(A) first that its value will be less than (B).

   I actually have the finer resolution timestamp support implemented
for Windows on my PC, but fell asleep yesterday trying to see why it
caused one of the tests ( to fail... wish I had
someone besides me for that debugging session... those timestamps,
internal file scanning targets and their relations to other targets is
driving me crazy... :-)

   Best regards,
     Jurko Gospodnetić

   Btw. I'm still not positive, but I think there might be a potential
problem in that test (and possibly others using the
same implementation pattern) that is causing it fail sporadically with
the current implementation but is uncovered completely by using a finer
timestamp resolution. It creates CPP & H targets from a FOO target in
its rule instead of the action. That causes those
targets to be created every time instead of 'only when needed'. With the
original implementation this 'most often makes no difference' because
those files are created so fast that their timestamps are very close to
the timestamp of the file requiring them and 1 second timestamp
resolution rounds them all up nicely to the same value. The problem
occurs only if their timestamp 'just passes the next 1 second mark' in
which case they get rounded to the next second. :-)

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at