On Thu, Mar 24, 2016 at 6:27 AM, Andrew Stitcher <[email protected]> wrote:
> On Thu, 2016-03-24 at 06:08 -0700, Justin Ross wrote: > > "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. > > True, but actually using the object itself is really clear to the user > - it's effectively an actor model operation - sending a specific > operation to a specific object, and the container might not be > available to the code in a handler that needs to inject an operation. > > Also bear in mind that container is not going to be available > everywhere, but you'll need to inject operations everywhere and it > would good to have a common way to do this. > I like the object-scoped injects too. > > > > 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. > > In that case it doesn't actually need to be serialised in the container > per se, so injecting doesn't help - it doesn't harm per se either - > it's just irrelevant. > > Injecting *only* helps to serialise against something that is > serialised by the implementation (qpid-proton-cpp) in the first place! > > If you need to do something to a object that is not serialised in the > API, queues might be a good example, then you will need to do it some > other way like holding locks. > I think I don't understand what you're saying. I don't need locking to modify objects (queues for instance) in the container serialization context. That's the point: code I inject there is only ever executed in sequence by the container event loop.
