Opened 12 years ago

Closed 12 years ago

#5409 closed Bugs (fixed)

Creation of the named mutex may take even 1.5 minute

Reported by: habdank@… Owned by: Ion Gaztañaga
Milestone: To Be Determined Component: interprocess
Version: Boost 1.45.0 Severity: Showstopper
Keywords: Cc:

Description

Dears,

We faced the problem that creation of the named mutex may take up to 1.5 minutes(!). We had been able to debug which function call is really using that amount of time.

In the file:

boost\interprocess\detail\tmp_dir_helpers.hpp

in the function:

inline void tmp_folder(std::string &tmp_name) {

get_tmp_base_dir(tmp_name); #ifdef BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME tmp_name += "/"; get_bootstamp(tmp_name, true); #endif

}

call to get_bootstamp(tmp_name, true); is waiting VERY long time. We saw that this function is using some WMI to get timestamp.

We found that there are other methods to obtain boot time. Maybe that will be helpful and those methods are not using expensive calls to WMI:

http://cpp.canbal.com/view.php?sessionid=qAo6EkHmKh9INoDkejiDum9LBQNvGWi2yoDfERxglB4%3D

http://stackoverflow.com/questions/5411140/retrieving-boot-time-using-gettickcount64

As that was a show stopper for us, we commented out parts of that function, so our function looks like:

inline void tmp_folder(std::string &tmp_name) {

get_tmp_base_dir(tmp_name); #ifdef BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME tmp_name += "/"; get_bootstamp(tmp_name, true); #endif

}

It is not nice, but it works (for us) :-).

Best regards, Seweryn.

Attachments (1)

tmp_dir_helpers_hpp.patch (614 bytes ) - added by anonymous 12 years ago.

Download all attachments as: .zip

Change History (3)

by anonymous, 12 years ago

Attachment: tmp_dir_helpers_hpp.patch added

comment:1 by Ion Gaztañaga, 12 years ago

Those methods don't help much to get a real timestamp that won't change with clock changes, hibernations, etc.

Finding a method to obtain a bootstamp (using kernel internals or WMI) in windows so that shared memory, queues, etc are erased when rebooting a machine have brought more problems than solutions.

I will disable bootstamp in new versions. POSIX allows shared memory to survive a reboot and that's what we'll have in Windows until someone finds a better method.

comment:2 by Ion Gaztañaga, 12 years ago

Resolution: fixed
Status: newclosed

WMI is provoking a lot of problems for Boost Interprocess users. I've decided to remove bootstamp use in windows to obtain kernel persistence in Windows. This means that windows shared memory/queues will survive to reboots, but this behaviour is allowed by POSIX. Using bootstamps to detect reboots is doing more harm than good.

WMI is removed in Boost 1.47

Note: See TracTickets for help on using tickets.