Re: [Boost-build] [Boost-commit] svn:boost r79511 - trunk/tools/build/v2/engine

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

   Hi.

>> 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 (dependency_test.py) 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ć

P.S.
   Btw. I'm still not positive, but I think there might be a potential 
problem in that dependency_test.py 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 foo.foo rule instead of the foo.foo 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. :-)