[rabbitmq-discuss] Multi-threading in c/c++
alan.antonuk at gmail.com
Fri Feb 17 05:37:52 GMT 2012
AMQP as a spec, only really specifies how clients and brokers should talk
to each other, and the features that brokers should expose to clients. It
leaves the programming API open to interpretation. The rabbitmq-c library
exposes a pretty raw and low-level interface to AMQP. It doesn't make any
effort to solve common messaging idioms (like RPC, or a multi-threaded
consumer), leaving that to the user of the library.
I hope to address this in a future version of the library, by making these
these a part of the API or providing a higher-level API that provides
solutions for these messaging patterns.
On Thu, Feb 16, 2012 at 9:41 PM, Eric J. Holtman <eric at holtmans.com> wrote:
> On 2/16/2012 7:27 PM, Alan Antonuk wrote:
> > Thats one way to do it. Another would be to a have a "connection thread"
> > that would own the non-thread-safe objects, and would dispatch the
> > to the worker threads. It takes a bit more code to accomplish it but its
> > As a self-less plug, if you're looking for a C++ wrapper - I'd encourage
> > you to checkout SimpleAmqpClient
> > which is Yet Another rabbitmq-c wrapper. It won't necessarily solve your
> > threading question though.
> Thanks, Alan!
> I guess after reading through a couple of books, I was assuming
> that implementations of Rabbit (or AMQP) would make using multiple
> channels across threads easier.
> However, I spent today glancing over the actual protocol spec,
> and now I understand why rabittmq-c doesn't do that: there's
> just way too much state in each object.
> OK, I can live with it... I just wanted to be sure I wasn't
> fundamentally misunderstanding something.
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss