Re: [Boost-users] [IPC Named Mutex]
One thing you could try...in interprocess's win32_api.hpp, there is another implementation of get_last_bootup_time() which uses WMI instead of the event log (there were warnings in the source about WMI not supporting hibernation/clock changes correctly, so beware). If you define BOOST_INTERPROCESS_BOOTSTAMP_IS_LASTBOOTUPTIME it should use that other version...give that a try. (in visual studio Project Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions: add a semi colon ';' then t
Thanks Tom, I'll try to fallback to the "old" WMI version (which BTW worked in the 1.44 version I we used before) I'd also be glad to fix it by myself and so help boost developement, , but I do not completely understand the usage of the system boot time... If boost needs in some way a tmestamp to differentiate things, in my opinion there are plenty of them to use instead of the last boot time. Obviously it has been done for a reason, but I cannot understand why :-D Best regards Lorenzo
On 17/04/2015 02:10, Lorenzo Trivelli wrote:
I'd also be glad to fix it by myself and so help boost developement, , but I do not completely understand the usage of the system boot time... If boost needs in some way a tmestamp to differentiate things, in my opinion there are plenty of them to use instead of the last boot time.
Obviously it has been done for a reason, but I cannot understand why :-D
I'm not really all that familiar with Interprocess, but my understanding is that it uses the filesystem for some of its constructs (which I think is weird and wrong, and likely a side effect of having Posix origins, but that's a topic for another day). Given that the failure was somewhere related to directory names, what's probably happening is that it's trying to find the name of its shared directory. For that it evidently wants to use the boot time, as it's a value that should be identical for all processes started since the last reboot, but different between reboots (to avoid getting stale data).
El 26/05/2015 a las 8:08, Gavin Lambert escribió:
I'm not really all that familiar with Interprocess, but my understanding is that it uses the filesystem for some of its constructs (which I think is weird and wrong, and likely a side effect of having Posix origins, but that's a topic for another day).
Given that the failure was somewhere related to directory names, what's probably happening is that it's trying to find the name of its shared directory. For that it evidently wants to use the boot time, as it's a value that should be identical for all processes started since the last reboot, but different between reboots (to avoid getting stale data).
Yes, that's the idea. Obtaining this "unique" identifier between reboots that remains stable between all processes it's been incredibly difficult. Any alternative or suggestion is welcome. Best, Ion
On 28/05/2015 04:00, Ion Gaztañaga wrote:
El 26/05/2015 a las 8:08, Gavin Lambert escribió:
Given that the failure was somewhere related to directory names, what's probably happening is that it's trying to find the name of its shared directory. For that it evidently wants to use the boot time, as it's a value that should be identical for all processes started since the last reboot, but different between reboots (to avoid getting stale data).
Yes, that's the idea. Obtaining this "unique" identifier between reboots that remains stable between all processes it's been incredibly difficult. Any alternative or suggestion is welcome.
Use CreateFileMapping to create a named (simple constant name) mapping *not* backed by a file. Store whatever data you want in here; this can include a randomly-generated value used to look up other items if you wish (generated by the first process to create the mapping and then used by all subsequent processes -- you may need to use a mutex either within the mapping or via CreateMutex to resolve races if multiple processes simultaneously access the mapping for the first time). The mapping data will automatically exist only until the next reboot or until the last application using it closes it. (It will also by default exist only for the current user session, which is usually what you want.) For IPC between concurrently running processes, this is usually sufficient -- the only case it can't handle is if you want to support running process A which leaves some "shared" object in a particular state but then exits before process B starts and expects to be able to read that state. But that would be a very weird design. Unless there's some really compelling reason not to, you should really store all the IPC data in the kernel namespace rather than the filesystem. Filesystems are slow.
El 28/05/2015 a las 1:25, Gavin Lambert escribió:
On 28/05/2015 04:00, Ion Gaztañaga wrote:
El 26/05/2015 a las 8:08, Gavin Lambert escribió:
Given that the failure was somewhere related to directory names, what's probably happening is that it's trying to find the name of its shared directory. For that it evidently wants to use the boot time, as it's a value that should be identical for all processes started since the last reboot, but different between reboots (to avoid getting stale data).
Yes, that's the idea. Obtaining this "unique" identifier between reboots that remains stable between all processes it's been incredibly difficult. Any alternative or suggestion is welcome.
Use CreateFileMapping to create a named (simple constant name) mapping *not* backed by a file. Store whatever data you want in here; this can include a randomly-generated value used to look up other items if you wish (generated by the first process to create the mapping and then used by all subsequent processes -- you may need to use a mutex either within the mapping or via CreateMutex to resolve races if multiple processes simultaneously access the mapping for the first time).
If all processes close the mapping, that mapping disappears and Interprocess shared memory must have kernel lifetime (POSIX semantics). SEe http://www.boost.org/doc/libs/1_55_0/doc/html/interprocess/some_basic_explan... We need something that remains stable even if all processes using it are killed, launch a new one and connect to this resource. Only after the machine is rebooted the resource disappears. Ion
On 27 May 2015 at 18:00, Ion Gaztañaga wrote:
Given that the failure was somewhere related to directory names, what's probably happening is that it's trying to find the name of its shared directory. For that it evidently wants to use the boot time, as it's a value that should be identical for all processes started since the last reboot, but different between reboots (to avoid getting stale data).
Yes, that's the idea. Obtaining this "unique" identifier between reboots that remains stable between all processes it's been incredibly difficult. Any alternative or suggestion is welcome.
On Windows you can mark a filing system entry as always deleted on close. Such an entry will be deleted on close no matter what, including power loss and filesystem corruption (the chkdsk with delete such still existing items). If you therefore need a synchronisation object to exist only for this boot cycle and to always disappear in the next boot cycle, delete on close is an excellent way of doing it. Why the Windows Temp files don't default to delete on close is beyond me (you can also unset delete on close at any time on an open file handle). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
El 28/05/2015 a las 12:13, Niall Douglas escribió:
On 27 May 2015 at 18:00, Ion Gaztañaga wrote:
Given that the failure was somewhere related to directory names, what's probably happening is that it's trying to find the name of its shared directory. For that it evidently wants to use the boot time, as it's a value that should be identical for all processes started since the last reboot, but different between reboots (to avoid getting stale data).
Yes, that's the idea. Obtaining this "unique" identifier between reboots that remains stable between all processes it's been incredibly difficult. Any alternative or suggestion is welcome.
On Windows you can mark a filing system entry as always deleted on close. Such an entry will be deleted on close no matter what, including power loss and filesystem corruption (the chkdsk with delete such still existing items).
If you therefore need a synchronisation object to exist only for this boot cycle and to always disappear in the next boot cycle, delete on close is an excellent way of doing it. Why the Windows Temp files don't default to delete on close is beyond me (you can also unset delete on close at any time on an open file handle).
Can you elaborate, please? What's a "filling system entry"? Delete-on-close would delete the resource when the last attached process exits, so it would be deleted before system reboot a new processes could not connect to the resource. Or am I missing something? Thanks Ion
On May 28, 2015 2:50:48 PM EDT, "Ion Gaztañaga" <igaztanaga@gmail.com> wrote:
El 28/05/2015 a las 12:13, Niall Douglas escribió:
On 27 May 2015 at 18:00, Ion Gaztañaga wrote:
Given that the failure was somewhere related to directory names, what's probably happening is that it's trying to find the name of its shared directory. For that it evidently wants to use the boot time, as it's a value that should be identical for all processes started since the last reboot, but different between reboots (to avoid getting stale data).
Yes, that's the idea. Obtaining this "unique" identifier between reboots that remains stable between all processes it's been incredibly difficult. Any alternative or suggestion is welcome.
On Windows you can mark a filing system entry as always deleted on close. Such an entry will be deleted on close no matter what, including power loss and filesystem corruption (the chkdsk with delete such still existing items).
If you therefore need a synchronisation object to exist only for this boot cycle and to always disappear in the next boot cycle, delete on close is an excellent way of doing it. Why the Windows Temp files don't default to delete on close is beyond me (you can also unset delete on close at any time on an open file handle).
Can you elaborate, please? What's a "filling system entry"?
Delete-on-close would delete the resource when the last attached process exits, so it would be deleted before system reboot a new processes could not connect to the resource. Or am I missing something?
Wouldn't it be a moot point when all mutex consumers closed? Next one fires up and requests a brand new round of shared mutex.
Thanks
Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
El 28/05/2015 a las 21:02, Michael escribió:
On May 28, 2015 2:50:48 PM EDT, "Ion Gaztañaga" <igaztanaga@gmail.com> wrote:
El 28/05/2015 a las 12:13, Niall Douglas escribió:
On 27 May 2015 at 18:00, Ion Gaztañaga wrote:
Given that the failure was somewhere related to directory names, what's probably happening is that it's trying to find the name of its shared directory. For that it evidently wants to use the boot time, as it's a value that should be identical for all processes started since the last reboot, but different between reboots (to avoid getting stale data).
Yes, that's the idea. Obtaining this "unique" identifier between reboots that remains stable between all processes it's been incredibly difficult. Any alternative or suggestion is welcome.
On Windows you can mark a filing system entry as always deleted on close. Such an entry will be deleted on close no matter what, including power loss and filesystem corruption (the chkdsk with delete such still existing items).
If you therefore need a synchronisation object to exist only for this boot cycle and to always disappear in the next boot cycle, delete on close is an excellent way of doing it. Why the Windows Temp files don't default to delete on close is beyond me (you can also unset delete on close at any time on an open file handle).
Can you elaborate, please? What's a "filling system entry"?
Delete-on-close would delete the resource when the last attached process exits, so it would be deleted before system reboot a new processes could not connect to the resource. Or am I missing something?
Wouldn't it be a moot point when all mutex consumers closed? Next one fires up and requests a brand new round of shared mutex.
That could work with a mutex, half-work with a semaphore (the count should remain stable after the last process closes the handle) and broken for a shared memory object. The key is how to find a unique identifier that identifies each reboot. I've tried: -> kernel boot time. It changes when clock is adjusted -> WMI LastBootUpTime. A lot of problems with my poor implementation and problems after hibernation and clock changes. -> Look for event ID == 6005 (event log started) in the System event log: problems when too many events are appended to the log as that event is lost. Any ideas? Best, Ion
On Thu, May 28, 2015 at 3:41 PM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
El 28/05/2015 a las 21:02, Michael escribió:
On May 28, 2015 2:50:48 PM EDT, "Ion Gaztañaga" <igaztanaga@gmail.com> wrote:
El 28/05/2015 a las 12:13, Niall Douglas escribió:
On 27 May 2015 at 18:00, Ion Gaztañaga wrote:
Given that the failure was somewhere related to directory names,
what's
probably happening is that it's trying to find the name of its
shared
directory. For that it evidently wants to use the boot time, as
it's a
value that should be identical for all processes started since the
last
reboot, but different between reboots (to avoid getting stale
data).
Yes, that's the idea. Obtaining this "unique" identifier between
reboots
that remains stable between all processes it's been incredibly difficult. Any alternative or suggestion is welcome.
On Windows you can mark a filing system entry as always deleted on close. Such an entry will be deleted on close no matter what, including power loss and filesystem corruption (the chkdsk with delete such still existing items).
If you therefore need a synchronisation object to exist only for this boot cycle and to always disappear in the next boot cycle, delete on close is an excellent way of doing it. Why the Windows Temp files don't default to delete on close is beyond me (you can also unset delete on close at any time on an open file handle).
Can you elaborate, please? What's a "filling system entry"?
Delete-on-close would delete the resource when the last attached process exits, so it would be deleted before system reboot a new processes could not connect to the resource. Or am I missing something?
Wouldn't it be a moot point when all mutex consumers closed? Next one fires up and requests a brand new round of shared mutex.
That could work with a mutex, half-work with a semaphore (the count should remain stable after the last process closes the handle) and broken for a shared memory object.
The key is how to find a unique identifier that identifies each reboot. I've tried:
I'm not positive, but you would need to predetermine something about it. A resource, location, or what have you. Either a file, whether counting or not (i.e. sem.). Existing of that file, maybe uuid-named for uniqueness between sessions, single file (if content in directory), or something along these lines. As long as that protocol was adhered to, should be no problem?
-> kernel boot time. It changes when clock is adjusted -> WMI LastBootUpTime. A lot of problems with my poor implementation and problems after hibernation and clock changes. -> Look for event ID == 6005 (event log started) in the System event log: problems when too many events are appended to the log as that event is lost.
Any ideas?
Best,
Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 28 May 2015 at 20:50, Ion Gaztañaga wrote:
Delete-on-close would delete the resource when the last attached process exits, so it would be deleted before system reboot a new processes could not connect to the resource. Or am I missing something?
Thinking about it now, you can't open new handles to a delete on close marked file, so this isn't a workable idea. Sorry about the noise. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Good evening, I thought about a solution to find the last boot time stamp (in seconds) which should work The only limitation is that on Win2003/XP and earlier it works if and only of the server is not running for more than 47 days. The trick is: * use a combination of GetTickCount(/GetTickCount64 to get the ms since last boot * Use GetSystemTime to get current system Time * Next, with some int64 magic, get the boot time by subtracting the elapsed boot time from current time * Next, go back to a SYSTEMTIME structure * As there are some different time functions involved, it seems that the ms part is no completely reliable, but the other members are do you think it may work ? here is a little sample: #include <windows.h> #include <stdio.h> int main() { SYSTEMTIME st; ULONGLONG tk; ULONGLONG now; FILETIME ft; ULONGLONG u_boot; FILETIME ft_boot; SYSTEMTIME st_boot; GetSystemTime(&st); //current time tk = GetTickCount(); //millisenconds since last boot SystemTimeToFileTime(&st,&ft); now = * ((ULONGLONG*) &ft); u_boot = (now / 10000 - tk) * 10000; //get a FILETIME back ft_boot = * ((FILETIME*) &u_boot); FileTimeToSystemTime(&ft_boot,&st_boot); printf("\nFunction Parameters"); printf("\n\tTick Count : %u",tk); printf("\n\tSystem Time to FileTime: %I64d", now); printf("\n\tBoot Time in 100ns : %I64d", u_boot); printf("\nBoot Time Was : %04d-%02d-%02d %02d:%02d:%02d.%03d", st_boot.wYear, st_boot.wMonth,st_boot.wDay, st_boot.wHour, st_boot.wMinute,st_boot.wSecond,st_boot.wMilliseconds); } Regards L. Trivelli
participants (6)
-
Gavin Lambert -
Ion Gaztañaga -
Lorenzo Trivelli -
Michael -
Michael Powell
-
Niall Douglas