C++ / event loop integration, reSIProcate, boost::asio

[Daniel Pocock <da...@pocock.pro>]

Hi,

I've been looking at how Qpid Proton (C++) might integrate more closely
with reSIProcate applications.  Is there a way to give the container
some cycles from an existing event loop and then the container lets the
thread do other things?

At present I run the container in a separate thread.

Many reSIProcate applications have a loop like this[1] at the
application level, I've commented it:

   while ( !clientHandler.done )
   {
      // SipStack::process( millisecs )
      // calls select on all the transports, also handles timers
      // at the stack level
      stack.process(100);

      // DialogUsageManager::process()
      // This does the higher level processing of any messages that
      // came into the SipStack over any transport
      while(clientDum.process());


      // here we could call other things that need to run in
      // this thread



      // demo only loops so many times...
      if (n == 1000) clientHandler.done = true;
      if (!(n++ % 10)) cerr << "|/-\\"[(n/10)%4] << '\b';
   }
   return 0;


I've also done a few things with asio[2], I would also be interested in
any examples of how to use Qpid Proton with asio without having separate
threads.

Regards,

Daniel


1.
https://github.com/resiprocate/resiprocate/blob/master/resip/dum/test/basicRegister.cxx#L125
2. http://think-async.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: C++ / event loop integration, reSIProcate, boost::asio

[Alan Conway <ac...@redhat.com>]

On Wed, 2017-04-05 at 18:17 +0200, Daniel Pocock wrote:
> 
> Hi,
> 
> I've been looking at how Qpid Proton (C++) might integrate more
> closely
> with reSIProcate applications.��Is there a way to give the container
> some cycles from an existing event loop and then the container lets
> the
> thread do other things?
> 
> At present I run the container in a separate thread.
> 
> Many reSIProcate applications have a loop like this[1] at the
> application level, I've commented it:
> 
> ���while ( !clientHandler.done )
> ���{
> ������// SipStack::process( millisecs )
> ������// calls select on all the transports, also handles timers
> ������// at the stack level
> ������stack.process(100);
> 
> ������// DialogUsageManager::process()
> ������// This does the higher level processing of any messages that
> ������// came into the SipStack over any transport
> ������while(clientDum.process());
> 
> 
> ������// here we could call other things that need to run in
> ������// this thread
> 
> 
> 
> ������// demo only loops so many times...
> ������if (n == 1000) clientHandler.done = true;
> ������if (!(n++ % 10)) cerr << "|/-\\"[(n/10)%4] << '\b';
> ���}
> ���return 0;
> 
> 
> I've also done a few things with asio[2], I would also be interested
> in
> any examples of how to use Qpid Proton with asio without having
> separate
> threads.

This is close to my heart. There are a few options, depending on how
far down the stack you want to go. All of them use the same event
handling model so the main application code is the same but how it is
driven and serialized will differ.

The C++ connecton_driver bundles up everything associated with a single
connection https://alanconway.github.io/proton-cpp/io_page.html in a
pure bytes-in/bytes-out AMQP protocol engine with no threading or IO
code. It is very embeddable but you have to do all the
IO/threading/sync stuff yourself.

The C++ container aims to provide a better out-of-the box experience
for majority cases with threading and IO built in. We want it to be
flexible also but the first cut may be missing some use cases.

You can implement your own container in C++ and have total control
(e.g. replace use asio directly). There awas a C++ example of this in
the last release.�

However the  C++ binding is being re-implemented over the C proactor ht
tps://alanconway.github.io/proton-c/group__proactor.html#details so the
thinking going forward is if you want to go that deep, you can
implement a new proactor in C for arbitrary IO platforms, and then the
existing C++ binding will run over your proactor without change. ASIO
straddles the two cases since it's a C++ IO library. You could slot it
under the proactor C interface or go directly from the C++ binding.





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org