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.

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

Reply via email to