"I think the inject operation needs to operate on the actual object with which it needs to be serialised."
That's what container.inject as proposed does. The container defines the serialization context for all the work that is done there, including arbitrary code the user may want to inject. Having something that works against "process context" may be what I want. What if I want to purge queues that I've defined in that same context? It need not be anything to do with a connection. On Thu, Mar 24, 2016 at 5:50 AM, Andrew Stitcher <[email protected]> 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. > > 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. > > 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. > > Andrew > >
