Okay, then I think we're seeing the same picture more or less. The difference is that I think the container inject is important. The container API requires that the user give up their thread to run(). Having some way to thereafter control that thread is natural to want.
Agreeing I think with what you have said, I don't see a need for a container.inject-like facility for the multithreaded (connection-engine based) scenarios. On Thu, Mar 24, 2016 at 7:07 AM, Andrew Stitcher <[email protected]> wrote: > On Thu, 2016-03-24 at 06:59 -0700, Justin Ross wrote: > > ... > > 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. > > But that's only true in a single threaded environment, and in that case > it's also true you don't really need to inject either, because there > can be no actual concurrent execution going on. > > So what you say is true for container, but not for any more complex set > up. I thought we were trying to put together a more unified proposal > which would be usable in those too. > > BTW: An import point I failed to make clear before: > > Nothing in my proposal stops you from *also* having an inject that is > scoped to a container (or in fact any other object if you can figure > out its serialisation requirements) - I just don't think "container" > will be all that useful. > > Andrew > >
