On 11/25/07, Ion Gaztañaga
Stefan Arentz escribió:
I checked out boost trunk from svn and tried to compile a simple boost.interprocess example. Unfortunately it fails at a rather unexpected place:
% c++ doc_message_queueA.cpp -Itrunk -o doc_message_queueA % ./doc_message_queueA Assertion failed: (res == 0), function lock, file trunk/boost/interprocess/sync/posix/interprocess_mutex.hpp, line 116. zsh: abort ./a
The error code is 22, EINVAL.
I'm on OS X 10.5.1, maybe that is too new, or not yet tested?
It is not tested but your problem and another problem reported a couple of weeks ago are pretty strange. If Leopard now offers process-shared posix mutexes and native shared memory, in theory Interprocess code should work without problems, just like other Unixes, but I don't know what's happening.
I don't have access to the OS so I'll need some help to fix these issues. Meanwhile, try to undef BOOST_INTERPROCESS_POSIX_PROCESS_SHARED define
line 21. This will avoid native process-shared mutexes and conditions and Interprocess will work as in Mac Os 10.4
Thanks Ion. That did the trick. I'll check if Leopard actually has process-shared mutexes. I have another problem now. I am trying to create a simple cross-process consumer/producer example based on the doc_message_queue*.cpp examples. My producer looks like this: message_queue mq(create_only, "message_queue", 3600, sizeof(int)); for(int i = 0; i < 3600; ++i){ std::cout << "Publishing " << i << std::endl; mq.send(&i, sizeof(i), 0); sleep(1); } And the consumer like this: message_queue mq(open_only ,"message_queue"); unsigned int priority; std::size_t recvd_size; for(int i = 0; i < 10; ++i){ int number; mq.receive(&number, sizeof(number), recvd_size, priority); std::cout << "Consumed " << number << std::endl; } When I start the producer it starts filling the queue. When I run the consumer multiple times it first quickly grabs 10 numbers in the queue until it is empty and then i see the rest appear every second. So far so good. The problem is that when I kill or Control-C the consumer that the producer stops. I assume that this is because some lock is held by the consumer and the producer is waiting for it. Is there a way to release these locks when the consumer is killed? Or a way to detect this, so that I can release them manually or so? S.