Windows Python time.process_time bug

[boverhof]

Description

Logic uses assumes this time is in seconds and uses it to time when to kill the AspenConsumer and related processes. By default this maxWait is 150. Think this is a bug in the python time module on windows because this number is barely moving.

>>> import time
>>>
>>> time.process_time()
0.046875
>>>
>>> time.process_time()
0.046875
>>>
>>> time.process_time()
0.046875
>>>
>>>
>>> time.process_time()
0.046875
>>>
>>>
>>> time.process_time()
0.046875
>>> time.process_time()
0.046875
>>> time.process_time()
0.0625
>>>
>>>
>>> time.process_time()
0.0625
>>>

[boverhof]

https://docs.python.org/3/library/time.html

time.process_time() → [float](https://docs.python.org/3/library/functions.html#float)
Return the value (in fractional seconds) of the sum of the system and user CPU time of the current process. It does not include time elapsed during sleep. It is process-wide by definition. The reference point of the returned value is undefined, so that only the difference between the results of two calls is valid.

Use [process_time_ns()](https://docs.python.org/3/library/time.html#time.process_time_ns) to avoid the precision loss caused by the [float](https://docs.python.org/3/library/functions.html#float) type.

New in version 3.3.

[boverhof]

Solution

• Use time.time() rather than time.process_time()
• not sure when this happened but result in very long timeouts to kill misbehaving processes