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

...

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.

Interprocess is using an undocumented kernel structure to get the boot time, but I don't see how you consider it's boot plus system time (is this somewhere documented?). It's been reported that changing system time changes this boot time or that hibernation breaks this, but I've never noticed what you are reporting. I'm experimenting now with a (in theory) more robust WMI system call to get the boot time, but still far from a working solution.

okay ignore the part about my assumption that it had anything to do with system time, sorry about that misinformation. the problem is, i can call the function two times in a row and get two different numbers. note i'm using Parallels desktop (on my mac), and the GuestOS is Windows 7 64bit, but the fact that i'm running in a VM should certainly NOT affect something as fundamental as shared memory. i think you must be onto something, regarding the API used to get the boot time.

...

note i'm using Parallels desktop (on my mac), and the GuestOS is Windows 7 64bit, but the fact that i'm running in a VM should certainly NOT affect something as fundamental as shared memory.

But it seems it affects this undocumented API function, this does not happen outside the VM ;-)

Thanks for the report, I'll investigate this issue,

fyi: http://msdn.microsoft.com/en-us/library/ms724408%28VS.85%29.aspx

On 16/06/2010 08:06, Ion Gaztañaga wrote:

On 16/06/2010 7:35, David M. Cotter wrote:

...

fyi: http://msdn.microsoft.com/en-us/library/ms724408%28VS.85%29.aspx

I don't see what you mean, we need system boot stamp not boot time. I think the answer might be WMI LastBootUpTime:

http://msdn.microsoft.com/en-us/library/aa394239%28VS.85%29.aspx

However, obtaining this is not trivial, since we need to use COM through C:

http://msdn.microsoft.com/en-us/library/aa390423%28v=VS.85%29.aspx

And if we want to avoid windows header inclusions (that's current Interprocess approach), then things are a bit more complicated. But I'm working on it,

Best,

Ion _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Or how about: long long boot_time_in_milliseconds_since_epoch = current_time_in_milliseconds_since_epoch() - GetTickCount64(); Cheers, Jon

...

fyi: http://msdn.microsoft.com/en-us/library/ms724408%28VS.85%29.aspx I don't see what you mean, we need system boot stamp not boot time. mmm, ok, didn't realize that

...But I'm working on it

ok. is there a way to "subscribe" to a notification when this gets fixed or otherwise addressed? i suppose i could put a filter on "subject: [interprocess] (Win32) shared memory totally doesn't work", but that requires someone reply to this thread when it's updated?

...

ok. is there a way to "subscribe" to a notification when this gets fixed or otherwise addressed? i suppose i could put a filter on "subject: [interprocess] (Win32) shared memory totally doesn't work", but that requires someone reply to this thread when it's updated?

You could create a trac ticket. When it gets fixed, you will receive a notification. i suppose i need a bug number for that? Ion, is there a bug? or how do i create a trac ticket? (yes, i looked, sorry me=n00b)

i have filed my own bug https://svn.boost.org/trac/boost/ticket/4352