Re: [boost] [interprocess] Getting boot-up time is unreliable on Windows
On 22/12/2016 10:01, Thomas Dahms wrote:
Dear developers, dear Ion,
We are experiencing issues on Windows where boost::interprocess relies on a certain event in the system event log to get the system's boot-up time. This has proven to be unreliable, because that event is not always present in the log. In that case, initialization of boost::interprocess fails. Several bug reports exist for that issue, e.g. [1, 2].
Report [1] contains a proposed fix to use GetTickCount64() and there is an open PR with an alternative fix to fall back to WMI mechanisms [3]. I understand that the fix [1] would need some polishing, because GetTickCount64() is not available in pre-Vista.
Nevertheless, both proposed fixes have been uncommented and unconsidered for a while now. Is there any chance that the maintainers could look into this?
Thanks for the ping. I don't think GetTickCount64 is very reliable, as other methods also have problems with time correction, hibernation, fast bootup, etc. In [1] one the last bootup log is lost new processes won't be able to communicate with others. The same happens with [3] In http://www.boost.org/doc/libs/1_63_0/doc/html/interprocess/acknowledgements_... there are some instructions to give up on kernel persistence and define the directory at compile time or run-time. This is the best workaround so far. I've trying to find a solution with no luck. I tried: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\BootId in modern Windows systems but hybrid shutdown (default since Windows 8) does not seem to update it as kernel is suspended. Searching for a unique bootup id in windows that does not suffer when hibernating or correcting the RTC is really complicated. Any suggestion welcomed. Best, Ion
On 31/12/2016 10:31, Ion Gaztañaga wrote:
I've trying to find a solution with no luck. I tried:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\BootId
in modern Windows systems but hybrid shutdown (default since Windows 8) does not seem to update it as kernel is suspended. Searching for a unique bootup id in windows that does not suffer when hibernating or correcting the RTC is really complicated.
Any suggestion welcomed.
Have you tried: // error checking omitted for brevity STAT_WORKSTATION_0 *pstats; NetStatisticsGet(nullptr, SERVICE_WORKSTATION, 0, 0, &(LPBYTE)pstats); // inspect pstats->StatisticsStartTime here NetApiBufferFree(pstats); ? It's probably still not quite foolproof, as someone could restart the service, but it might help. Perhaps you could check multiple sources in the hope that at least one of them will return truth? If I understand the issue correctly, all that's really needed is to have a session id that's unique per boot and otherwise fixed. So the Real Problem™ is detecting when you need to reset the session id. You could do that by having a file in a well-known location (protected by standard locking mechanisms from multiple processes initialising at once) that contains a GUID and all the known possible boot times. If *any* of the boot times match, then the GUID is good and can be used as the communication directory name. If *none* of them match, then it's probably a new boot and you generate a new GUID and write the new id and boot sources to the file. (For cross-version compatibility, the file will have to have keys that describe the source of the boot time along with the value thus calculated. Apps would ignore unknown sources and append new values if they're happy with the session id but also know some source that wasn't listed. Or there's a few other options.) You could also backstop this with some native non-persistent shared memory with a well-known name that holds this session GUID as long as any Interprocess process is running -- on init you'd try to access this and if it works, you know it's good; otherwise you fall back to the file-based mechanism (and create the shared memory for the next process). Although it would also be nice if library users could opt-in to use shared memory with Windows semantics (it remains alive as long as at least one process is using it, otherwise it disappears -- aka process-persistence). This avoids the whole issue.
participants (2)
-
Gavin Lambert -
Ion Gaztañaga