On Thu, 2015-10-22 at 22:03 -0700, Cliff Jansen wrote: > I'm not sure if this exactly fits your question (especially the > multi-threaded part), but the python tornado loop examples run a > regular reactor set of events and collectors but driven by the > external loop. > > pn_iohandler is replaced with the TornadoLoophandler which knows how > to insert Proton io selectables into the external loop and provide > callbacks to do work when the external loop schedules activity on the > descriptor. > > Aside from program configuration on startup, the user code (e.g. > hello > world) knows nothing about the change and runs just as if under > Proton's own selector - the events it sees are the same. > > Something similar could be done with libuv in Proton-C, certainly > with > Posix, perhaps with some issues under Windows.
I understand that this can be done, but why? Proton is an AMQP protocol engine it is not a general purpose IO and event handling framework. I see the value of proton providing a simple IO framework for isolated proton projects when there is nothing else available. But if you already use tornado, epoll, ACE, boost IO, the Go net package, C++11 std::async, the proactor pattern etc. etc. then why would you want to write code to integrate that with a single-threaded, non-standard, C reactor? What is the reactor bringing to the party? You certainly want proton to handle AMQP for you, but you want to integrate it into your existing framework, not the other way around. The transport provides a simple bytes in/bytes out interface that is exactly what you need, and we can make it a little more user friendly. The reactor integration points create more work and more overhead to integrate with another IO framework, and if your framework is not select-like (e.g. the go net package) then the reactor integration points make no sense at all. > > Cliff > > On Thu, Oct 22, 2015 at 2:33 PM, aconway <acon...@redhat.com> wrote: > > The proton reactor provides a complete solution for integrating > > foreign > > IO into a single threaded proton event loop. This is useful in > > situations where proton is being used in isolation, there is no > > other > > IO handling framework available and everything is single threaded. > > > > However often that is not going to be the case. There are many > > existing C and C++ libraries for managing polling of file > > descriptors > > and dispatching of work, and most server applications that might > > want > > to embed proton already have their own frameworks. > > > > So I'm thinking about how we can make integrating proton into an > > existing (possibly multi-threaded) framework easier. I think all it > > requires is a few simple functions to pull data out of a file > > descriptor as events and push data back into a file descriptor, and > > make this easier than directly using the collector and transport. > > I've > > done it in Go already but I think it could be captured in C and C++ > > as > > well. > > > > Anyone already done something like this? > > > > Cheers, > > Alan. > > > > ------------------------------------------------------------------- > > -- > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
