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: [email protected]
For additional commands, e-mail: [email protected]
