On Thu, 2015-04-30 at 21:51 -0400, Rafael Schloming wrote: > What sort of work/connections are you talking about here? Are you talking > about processing AMQP messages in a thread pool or are you talking about > writing some sort of multithreaded I/O handler?
I'm talking about running multiple proton instances in a thread pool, like the Qpid C++ broker does. It uses a thread safe poller (based on epoll or somesuch) to dispatch data from many connections to a small thread pool. The poller serializes work per connection. There is a proton engine per connection so work to each engine is serialized but different engines run concurrently. The worker threads feed the proton transport, process events, and move messages to and from thread-safe queues (which are potentially shared among all connections) I'm trying to understand if the C reactor can help with that. I have the impression that the reactor requires all of the engines and their handlers to run in a single thread. From there I could put messages into a thread pool to process them concurrently. However the engines share no data so there is no reason not to run them in parallel as well. Serializing everything thru the reactor doesn't seem to buy me anything, but it reduces concurrency and makes the reactor thread a bottleneck. On the other hand, using a reactor per connection doesn't seem to give me anything over just using an engine per connection. I may have missed something though... Cheers, Alan. > > --Rafael > > On Thu, Apr 30, 2015 at 2:47 PM, Alan Conway <acon...@redhat.com> wrote: > > > Can the proton reactor be used to deliver work from multiple connections > > to a thread pool, where work from a given connection is only handled by > > one thread at a time (so access to each pn_transport and it's stuff is > > serialized)? That is a pretty standard model for servers. > > > > It doesn't look to me like this is the case but I may be missing > > something. If it is the case, what's the pattern for doing it? > > > > Cheers, > > Alan. > > > >
