On 01/17/2011 12:40 PM, Jason Schlauch wrote:
On Mon, Jan 17, 2011 at 10:33 AM, Alan Conway<[email protected]> wrote:
On 01/12/2011 10:48 AM, Niklas Röjemo wrote:
Hi All,
I have problem with interaction between fork and qpid when using qpid
from mrg 1.3. The program worked using mrg 1.1. The problem can be
...
int main(int argc, char** argv) {
const char* key = "rojemo_ts";
const char* exchange = "amq.direct";
const char* host = "qpid-vm";
int port = 5672;
for(int i = 0; i< 10; ++i) {
{
qpid::client::Connection connection;
connection.open(host, port);
qpid::client::Session session =
qpid::client::sync(connection.newSession());
qpid::client::Message message;
message.getDeliveryProperties().setRoutingKey(key);
message.setData("testing");
session.messageTransfer(qpid::client::arg::content=message,
qpid::client::arg::destination=exchange);
session.sync();
session.close();
connection.close();
}
{
pid_t pid = fork();
if(!pid) {
sleep(1);
exit(0);
} else {
int status;
wait(&status);
}
}
}
}
The qpid client library creates background threads, so forking a qpid client
like this won't work. For some info on why forking& pthreads don't coexist
well see the"Rationale" section of:
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html
In this particular example all qpid related variables will have gone
out of scope when fork() is called. Why do threads (or mutexes or any
other uncopyable constructs) still exist?
The qpid client library creates a process-wide thread pool that hangs around
even if you're not using it.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
