has nobody run into this issue? does anyone have any hint for me? i'm afraid to deploy release software with the "fix" below, i don't really know what the implications might be. -dave On Jun 14, 2010, at 5:21 PM, David M. Cotter wrote:
to be perfectly clear: each time i call get_system_time_of_day_information() , i get the SAME number in the high 32 bits but a DIFFERENT number in the low 32bits. of info.data.liKeBootTime.
if i do this right after the call: info.data.liKeBootTime &= 0xFFFFFFFF00000000;
then everything works as expected.
On Jun 14, 2010, at 4:28 PM, David M. Cotter wrote:
so in process A i do this:
shared_memory_object obj(create_only, "guid of some kind", read_write);
during the construction of that object, it makes a call to "get_boot_time_str()" to construct a folder name based on the boot time. this makes sense, so process B can locate the SAME folder, cuz the boot time is the same, right?
well, wrong.
you see, the function *says* get_BOOT_time, but it is actually getting boot PLUS SYSTEM (current) time. which is going to be different for the two processes, unless they made the call at the *exact* same time.
so it would seem, unless i'm totally misunderstanding this, that it is impossible to use the shared memory thing as it is implemented.
if i *remove* the part where it relies on SYSTEM time and only let it use BOOT time, everything works as documented and as expected.
what is this about? i'm so curious how other people could be using this?
-dave