Problem with boost::interprocess::ipc::message_queue
Hello Everybody, i used boost::interprocess::ipc::message_queue (boost 1.40) in my project. it works perfect. after upgrade from boost 1.40.0 to 1.46.0 i do have a problem with the message_queue. my usage of message_queue: Receiver: message_queue message_queue(open_or_create, strQueueName.c_str(), nMessagesNumber, nMessageLength); / .... bReceiveSucces = message_queue.try_receive(pchPuffer, m_nMessageLength, nRecievedSize, nPriority);/ Sender: message_queue message_queue(open_only, m_strMessageQueueName.c_str()); message_queue.try_send(strMessage.c_str(), nMessageLength, nPriority); (the Receiver is running before Sender has be started.) i readed the content in the output windows from Visual Studio 2008 (my building envoriment) during start of my application: * 1.40.0:* /'MessageQueueReceiver.exe': Loaded 'C:\data\20_NoBackup\Project\MessageQueueSender\Debug\MessageQueueReceiver.exe', Symbols loaded./ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll'/ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll'/ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll'/ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll'/ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\secur32.dll'/ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456\msvcr90d.dll', Symbols loaded./ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456\msvcp90d.dll', Symbols loaded./ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\shimeng.dll', Symbols loaded (source information stripped)./ /'MessageQueueReceiver.exe': Unloaded 'C:\WINDOWS\system32\shimeng.dll'/ the receiver-application loaded these dlls and waiting for the input message from the sender-application.. *1.46.0:* /MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\wbem\wbemprox.dll', Symbols loaded (source information stripped)./ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\wbem\wbemcomn.dll', Symbols loaded (source information stripped)./ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\ws2_32.dll', Symbols loaded (source information stripped)./ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\ws2help.dll', Symbols loaded (source information stripped)./ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\wbem\wbemsvc.dll', Symbols loaded (source information stripped)./ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\wbem\fastprox.dll'/ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\msvcp60.dll', Symbols loaded (source information stripped)./ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\ntdsapi.dll', Symbols loaded (source information stripped)./ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\dnsapi.dll'/ /'MessageQueueReceiver.exe': Loaded 'C:\WINDOWS\system32\wldap32.dll', Symbols loaded (source information stripped)./ /'MessageQueueReceiver.exe': Unloaded 'C:\WINDOWS\system32\wbem\fastprox.dll'/ /'MessageQueueReceiver.exe': Unloaded 'C:\WINDOWS\system32\ntdsapi.dll'/ /'MessageQueueReceiver.exe': Unloaded 'C:\WINDOWS\system32\wldap32.dll'/ /'MessageQueueReceiver.exe': Unloaded 'C:\WINDOWS\system32\dnsapi.dll'/ /'MessageQueueReceiver.exe': Unloaded 'C:\WINDOWS\system32\msvcp60.dll'/ /'MessageQueueReceiver.exe': Unloaded 'C:\WINDOWS\system32\wbem\wbemsvc.dll'/ /'MessageQueueReceiver.exe': Unloaded 'C:\WINDOWS\system32\wbem\wbemprox.dll'/ /'MessageQueueReceiver.exe': Unloaded 'C:\WINDOWS\system32\ws2_32.dll'/ /'MessageQueueReceiver.exe': Unloaded 'C:\WINDOWS\system32\ws2help.dll'/ /'MessageQueueReceiver.exe': Unloaded 'C:\WINDOWS\system32\wbem\wbemcomn.dll'/ ...................... ...................... ...................... the receiver-application loaded these complettly different Dlls (in compare with 1.40) and unloaded them repeatly (endless). if man compare the cruise of the message_queue, is 1.46.0 about 4 times slower as 1.40.0. do somebody know? is it a bug or just the sideeffect from the changement? how can i use the message_queue correctly? thanks a lot for any suggestion best regards Ming Lu
El 01/04/2011 9:57, Ming Lu escribió:
Hello Everybody,
i used boost::interprocess::ipc::message_queue (boost 1.40) in my project. it works perfect. after upgrade from boost 1.40.0 to 1.46.0 i do have a problem with the message_queue.
the receiver-application loaded these complettly different Dlls (in compare with 1.40) and unloaded them repeatly (endless).
Windows WMI functions are called when creating or unlinking shared memory or message queues. Sadly WMI usage is causing a lot of problems and it's use will be removed. That means that shared memory and message queues will survive to reboots, but that behavior is allowed by POSIX. My tries to use kenel bootstamp and WMI to achieve kernel lifetime have caused a lot of problems, so it's better to go back to the old, pre-boost 1.39 behaviour than continue receiving bugs. You can get the old behaviour commenting #define BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME in boost/interprocess/detail/tmp_helpers.hpp Best, Ion
Hallo Ion, thanks a lot for your help! Your suggestion works brillant. but is a littel problem: By start my application throw the visual studio 2 exceptions: First-chance exception at 0x7c812afb in WindowsDataCollector.exe: Microsoft C++ exception: boost::interprocess::interprocess_exception at memory location 0x00efe5d8.. First-chance exception at 0x7c812afb in WindowsDataCollector.exe: Microsoft C++ exception: boost::interprocess::interprocess_exception at memory location 0x00efe58c.. but the application works without any problem. is that normally? Thanks again Best regards Ming On 01.04.2011 18:58, Ion Gaztañaga wrote:
El 01/04/2011 9:57, Ming Lu escribió:
Hello Everybody,
i used boost::interprocess::ipc::message_queue (boost 1.40) in my project. it works perfect. after upgrade from boost 1.40.0 to 1.46.0 i do have a problem with the message_queue.
the receiver-application loaded these complettly different Dlls (in compare with 1.40) and unloaded them repeatly (endless).
Windows WMI functions are called when creating or unlinking shared memory or message queues. Sadly WMI usage is causing a lot of problems and it's use will be removed. That means that shared memory and message queues will survive to reboots, but that behavior is allowed by POSIX. My tries to use kenel bootstamp and WMI to achieve kernel lifetime have caused a lot of problems, so it's better to go back to the old, pre-boost 1.39 behaviour than continue receiving bugs.
You can get the old behaviour commenting
#define BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME
in boost/interprocess/detail/tmp_helpers.hpp
Best,
Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
El 04/04/2011 10:33, Ming Lu escribió:
Hallo Ion,
thanks a lot for your help! Your suggestion works brillant. but is a littel problem:
By start my application throw the visual studio 2 exceptions:
First-chance exception at 0x7c812afb in WindowsDataCollector.exe: Microsoft C++ exception: boost::interprocess::interprocess_exception at memory location 0x00efe5d8.. First-chance exception at 0x7c812afb in WindowsDataCollector.exe: Microsoft C++ exception: boost::interprocess::interprocess_exception at memory location 0x00efe58c..
but the application works without any problem. is that normally?
I don't know, it might be normal if those exceptions are used internally for some reason. You will need to catch where are they thrown so that I can deduce if it's working correctly. Ion
Hello Ion, another question. your answer sounds that is a common bug? will it be fixed? if yes, when will be happens? best regards Ming On 01.04.2011 18:58, Ion Gaztañaga wrote:
El 01/04/2011 9:57, Ming Lu escribió:
Hello Everybody,
i used boost::interprocess::ipc::message_queue (boost 1.40) in my project. it works perfect. after upgrade from boost 1.40.0 to 1.46.0 i do have a problem with the message_queue.
the receiver-application loaded these complettly different Dlls (in compare with 1.40) and unloaded them repeatly (endless).
Windows WMI functions are called when creating or unlinking shared memory or message queues. Sadly WMI usage is causing a lot of problems and it's use will be removed. That means that shared memory and message queues will survive to reboots, but that behavior is allowed by POSIX. My tries to use kenel bootstamp and WMI to achieve kernel lifetime have caused a lot of problems, so it's better to go back to the old, pre-boost 1.39 behaviour than continue receiving bugs.
You can get the old behaviour commenting
#define BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME
in boost/interprocess/detail/tmp_helpers.hpp
Best,
Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hello Ion, do you know when 1.47 will be released? Best regards Ming On 04.04.2011 22:44, Ion Gaztañaga wrote:
El 04/04/2011 11:37, Ming Lu escribió:
Hello Ion,
another question. your answer sounds that is a common bug? will it be fixed? if yes, when will be happens?
best regards Ming
Boost 1.47
Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Apr 5, 2011, at 2:21 AM, Ming Lu wrote:
Hello Ion,
do you know when 1.47 will be released?
I believe that the goal is 2-May. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
participants (3)
-
Ion Gaztañaga -
Marshall Clow -
Ming Lu