I should say why I favor the event loop-level inject for container, but not for the connection engine scenarios. In the former, we are providing the event loop (in the form of a convenience class, Container). In the latter, we are requiring the user to bring their own event loop or loops. As a consequence, they are responsible for implementing any serialization guarantees.
On Thu, Mar 24, 2016 at 7:16 AM, Justin Ross <[email protected]> wrote: > 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 > > > > >
