Wait until a newly assigned file system modification timestamp for the given path is large enough for the timestamp difference between it and the last build timestamp or the path's original file system modification timestamp (depending on the last_build_time flag)
(self, path, touch, last_build_time)
| 1064 | return result |
| 1065 | |
| 1066 | def __wait_for_time_change(self, path, touch, last_build_time): |
| 1067 | """ |
| 1068 | Wait until a newly assigned file system modification timestamp for |
| 1069 | the given path is large enough for the timestamp difference between it |
| 1070 | and the last build timestamp or the path's original file system |
| 1071 | modification timestamp (depending on the last_build_time flag) to be |
| 1072 | correctly recognized by both this Python based testing framework and |
| 1073 | the Boost Jam executable being tested. May optionally touch the given |
| 1074 | path to set its modification timestamp to the new value. |
| 1075 | |
| 1076 | """ |
| 1077 | assert self.last_build_timestamp or not last_build_time |
| 1078 | stats_orig = os.stat(path) |
| 1079 | |
| 1080 | if last_build_time: |
| 1081 | start_time = self.last_build_timestamp |
| 1082 | else: |
| 1083 | start_time = stats_orig.st_mtime |
| 1084 | |
| 1085 | build_resolution = self.__build_timestamp_resolution() |
| 1086 | assert build_resolution >= 0 |
| 1087 | |
| 1088 | # Check whether the current timestamp is already new enough. |
| 1089 | if stats_orig.st_mtime > start_time and (not build_resolution or |
| 1090 | stats_orig.st_mtime >= start_time + build_resolution): |
| 1091 | return |
| 1092 | |
| 1093 | resolution = self.__python_timestamp_resolution(path, build_resolution) |
| 1094 | assert resolution >= build_resolution |
| 1095 | |
| 1096 | # Implementation notes: |
| 1097 | # * Theoretically time.sleep() API might get interrupted too soon |
| 1098 | # (never actually encountered). |
| 1099 | # * We encountered cases where we sleep just long enough for the |
| 1100 | # filesystem's modifiction timestamp to change to the desired value, |
| 1101 | # but after waking up, the read timestamp is still just a tiny bit |
| 1102 | # too small (encountered on Windows). This is most likely caused by |
| 1103 | # imprecise floating point timestamp & sleep interval representation |
| 1104 | # used by Python. Note though that we never encountered a case where |
| 1105 | # more than one additional tiny sleep() call was needed to remedy |
| 1106 | # the situation. |
| 1107 | # * We try to wait long enough for the timestamp to change, but do not |
| 1108 | # want to waste processing time by waiting too long. The main |
| 1109 | # problem is that when we have a coarse resolution, the actual times |
| 1110 | # get rounded and we do not know the exact sleep time needed for the |
| 1111 | # difference between two such times to pass. E.g. if we have a 1 |
| 1112 | # second resolution and the original and the current file timestamps |
| 1113 | # are both 10 seconds then it could be that the current time is |
| 1114 | # 10.99 seconds and that we can wait for just one hundredth of a |
| 1115 | # second for the current file timestamp to reach its next value, and |
| 1116 | # using a longer sleep interval than that would just be wasting |
| 1117 | # time. |
| 1118 | while True: |
| 1119 | os.utime(path, None) |
| 1120 | c = os.stat(path).st_mtime |
| 1121 | if resolution: |
| 1122 | if c > start_time and (not build_resolution or c >= start_time |
| 1123 | + build_resolution): |
no test coverage detected