[c++] Multi-threaded proton and C++11

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

I am working on a multi-threaded broker example for proton C++ and I am
becoming more and more convinced that it doesn't make much sense to try
to do this without C++11.

There are two classes of issue:

API:
- inject() needs a way to represent a callback function. Without
std::function this is very difficult.
- for memory-safe multi-threaded we will need to expose
shared_ptr/unique_ptr in the public API (the proton refcounting scheme
is not thread safe.)

Implementation: initially the multi-threaded broker impl will be
independent of the single-threaded proton core but at some point we
will want to provide some thread-safe toolkit as part of the C++ API,
which internally needs atomics, mutexes etc.

Originally we talked about keeping proton based on C++03. I'd like to
propose we maintain that for the single-threaded but use C++11 in
thread-safe and shared_ptr extensions.

If someone wants to add a boost version of those extensions at some
point that would be fine by me, but I plan to work initially with
C++11.

Thoughts?
Alan.

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

Re: [c++] Multi-threaded proton and C++11

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

On Mon, 2016-04-04 at 09:55 +0200, Mark Banner wrote:
> I completely agree Alan. We have recently been doing something very
> similar
> internally in C++03 and the C++11 primitives are sourly missed. We
> have
> managed to not use std::function by having a certain number of
> hardcoded
> events which can be sent to a connection engine and using custom
> promises/futures to retrieve the result.
> Overall a lot of complexity is added by reimplementing features which
> are
> available in C++11.

Glad to hear I'm not off the rails. I'm putting together an example of
an epoll-based broker as the first cut. It uses C++11 but doesn't touch
the existing C++03 core. Then I will look at factoring the re-usable
parts of the example into a "detachable" mult-threaded extension API.

Detachable 2 senses:

1. you can still build and use the core API with C++03 but you won't
get the benefits of the multi-threaded extension API. That's fine for
single threaded users or users who already have chosen an external
threading framework and don't want/need any proton help with that.

2. we could implement another version of the MT extension API using
boost or some other framework if there is demand. Now that C++11 has
standard tools, it seems less likely that there will be demand but we
aren't ruling it out.

> 
> On Fri, Apr 1, 2016 at 5:47 PM, Alan Conway <ac...@redhat.com>
> wrote:
> 
> > 
> > I am working on a multi-threaded broker example for proton C++ and
> > I am
> > becoming more and more convinced that it doesn't make much sense to
> > try
> > to do this without C++11.
> > 
> > There are two classes of issue:
> > 
> > API:
> > - inject() needs a way to represent a callback function. Without
> > std::function this is very difficult.
> > - for memory-safe multi-threaded we will need to expose
> > shared_ptr/unique_ptr in the public API (the proton refcounting
> > scheme
> > is not thread safe.)
> > 
> > Implementation: initially the multi-threaded broker impl will be
> > independent of the single-threaded proton core but at some point we
> > will want to provide some thread-safe toolkit as part of the C++
> > API,
> > which internally needs atomics, mutexes etc.
> > 
> > Originally we talked about keeping proton based on C++03. I'd like
> > to
> > propose we maintain that for the single-threaded but use C++11 in
> > thread-safe and shared_ptr extensions.
> > 
> > If someone wants to add a boost version of those extensions at some
> > point that would be fine by me, but I plan to work initially with
> > C++11.
> > 
> > Thoughts?
> > Alan.
> > 
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> > 
> > 

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

Re: [c++] Multi-threaded proton and C++11

[Mark Banner <ma...@gmail.com>]

I completely agree Alan. We have recently been doing something very similar
internally in C++03 and the C++11 primitives are sourly missed. We have
managed to not use std::function by having a certain number of hardcoded
events which can be sent to a connection engine and using custom
promises/futures to retrieve the result.
Overall a lot of complexity is added by reimplementing features which are
available in C++11.

On Fri, Apr 1, 2016 at 5:47 PM, Alan Conway <ac...@redhat.com> wrote:

> I am working on a multi-threaded broker example for proton C++ and I am
> becoming more and more convinced that it doesn't make much sense to try
> to do this without C++11.
>
> There are two classes of issue:
>
> API:
> - inject() needs a way to represent a callback function. Without
> std::function this is very difficult.
> - for memory-safe multi-threaded we will need to expose
> shared_ptr/unique_ptr in the public API (the proton refcounting scheme
> is not thread safe.)
>
> Implementation: initially the multi-threaded broker impl will be
> independent of the single-threaded proton core but at some point we
> will want to provide some thread-safe toolkit as part of the C++ API,
> which internally needs atomics, mutexes etc.
>
> Originally we talked about keeping proton based on C++03. I'd like to
> propose we maintain that for the single-threaded but use C++11 in
> thread-safe and shared_ptr extensions.
>
> If someone wants to add a boost version of those extensions at some
> point that would be fine by me, but I plan to work initially with
> C++11.
>
> Thoughts?
> Alan.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>