WIN32: IOC scan loops hang

I observed an a Windows areaDetector IOC not updating the ArrayRate_RBV records when it should. It appeared that the 1 second scan was not running. Restarting the IOC fixed the problem. This is consistent with this bug

Use of GetTickCount64() seems reasonable to me, it does close the door on XP compatibility though.

I guess this is an preview of 2038. So it may be worthwhile to investigate if epicsTimeDiffInSeconds() can be made to handle rollover reasonably.

Hi Freddie, which version of Base are you using here? I thought the code that used the monotonic clock in the internal timer queues never got into a released version, but I just found that dbScan.c is calling epicsTimeGetMonotonic() in its periodic scan code (from commit 8b9ad212c4eb43d) so it seems I was wrong, that code has been in all releases since 7.0.3.1.

I have added GetTickCount64() wrapped in a _WIN32_WINNT check, so it is still possible to compile for Windows XP by defining _WIN32_WINNT as 0x0501 externally

We are running base 7.0.3.1

> ... I thought the code that used the monotonic clock in the internal timer queues never got into a released version ...

dbScan.c was the one usage I still had confidence in, so I left it. sigh...

epicsTimeDiffInSeconds() only tries to handle rollover >= `ULONG_MAX/2`. Using it with a time source which rolls over sooner is wrong, and likely unfixable.

And for that matter, use of `ULONG_MAX` seems wrong on targets where `sizeof(long)==8`. eg. if:

> epicsTimeStamp A = {0xffffffff, 0};
> epicsTimeStamp B = {0x00000001, 0};

Then epicsTimeDiffInSeconds(&B, &A) should be 2.0 right?

On Linux, I get -4294967294.0

Down the rabbit hole we go...

QueryPerformanceCounter() is likely to work on Windows 2000 and above, and guaranteed to work on Windows XP and above so I have removed use of either GetTickCount() or GetTickCount64() in the PR

Cross-linking: epicsTime: fix overflow handling

https://github.com/epics-base/epics-base/pull/92

The problem of scan threads hanging was fixed by reversion of the use of monotonic time for timers, but the underlying issue with the monotonic time support on Windows has now been fixed by Freddie's branch.

My previous comment was incorrect, this bug has been present since 7.0.3.1 and should finally be fixed in the up-coming 7.0.5 release.