qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: [c++] Proposal for application function injection.
Date Thu, 24 Mar 2016 17:59:24 GMT
On Thu, 2016-03-24 at 08:50 -0400, Andrew Stitcher wrote:
> On Mon, 2016-03-21 at 14:36 -0400, Alan Conway wrote:
> > 
> > ...
> > > 
> > > > 
> > > >  
> > 1. which event loop are you injecting into. I think once we have
> > connections in more than one thread we'll need to inject into a
> > specific connection, not just into the container. Something like
> > 
> I've thought about it a bit more and my thinking has changed a little
> bit from this:
> 
> I think the inject operation needs to operate on the actual object
> with
> which it needs to be serialised. So minimally the inject should act
> on
> the connection (not the container):
> 
> class connection {
> ...
> 	void inject(std::function<void(connection&)>);
> ...
> }
> 
> Note that the function also passes in the connection - this is not
> 100%
> necessary, but it seems to me that it is so likely to be needed that
> leaving it off is pointless, again std::bind can be used to add any
> other necessary context.

Disagree. Example:

connection c = ...;
sender s = c.open_sender(...);
message m = ...;

c.inject([s, m]() { s.send(m); }); // Capture
c.inject(std::bind(sender::send, s, m)); // Bind

The API is very easy to use without requiring a connection parameter on
inject, indeed requiring it would be more awkward:

c.inject([s,m](connection) { s.send(m); }); // Useless parameter

You can't use std::bind directly at all in this case since, sender::send doesn't take a connection
parameter so you are forced to use a lambda or create a new function just so you can ignore
the connection.

> I'd also be in favour of having inject operations on session, sender
> &
> receiver for convenience too - but I think these could be wrappers
> over
> the basic connection::inject.

Agreed. Actually then having the parameter would make more sense but is
still not necessary IMO, I'd rather keep it simple.

> 
> Incidentally I think that this would be the best model for timed
> events
> too.
> 
> The logic for this is that the API user knows which object's context
> he
> wants to inject events into and stating this clearly (instead of
> having
> to use a proxy like the container or something related to the event
> loop) is just more error prone.
> 
> This does strongly imply that the connection does need to know about
> the actual event loop implementation though so it can forward the
> injection to the correct driver - this in turn means that there would
> need to be a common SPI interface at this level for injecting events.

Yes, I think that will be the case.


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


Mime
View raw message