GetProcessTimes and GetProcessIoCounters#959
GetProcessTimes and GetProcessIoCounters#959matthiasblaesing merged 2 commits intojava-native-access:masterfrom
Conversation
| // lpExitTime is undefined for a running process, do not test | ||
| // Kernel and User time must be >= 0 | ||
| assertTrue(lpKernelTime.toTime() >= 0); | ||
| assertTrue(lpUserTime.toTime() >= 0); |
There was a problem hiding this comment.
The asserts in lines 401 and 402 fail for me. The conversion in WinBase#FILETIME is implemented under the assumption, that a FILETIME is a timestamp. In this case this is wrong. the kernel and user times are relative times, that the process accumulated in user-/kernelmode. Two options: use FILEMTIME#toDWordLong or add a conversion to long to FILEMTIME.
The method binding for GetProcessTimes looks good, it is just the test, that das not work.
|
Whoops. My local version/test only used start time and got kernel/user from other sources. I added that at the last minute and forgot FILETIME uses the 1601 epoch. DWORDLONG is the way to go here but since the value represents an unsigned long, a >= 0 test is silly. I’ll calculate an up time from the start time and calculate max ticks... |
|
Thanks - this looks good. In theory the unittest could fail, as the kernel and user times are counted per thread according to MSDN. I looked at the numbers and at this time I think we should be save, if we see a problem at a later time we can still introduce a multiplier. |
|
Ah, good point that you can get > 100% utilization on a multi-core processor. But the JUnit tests are single threaded, right? |
|
The JUnit tests are single threaded, but there are background threads (GC). In practice I don't expect problems. |
2 participants
No description provided.