> On 27 Apr 2017, at 16:41, Michael McMahon <michael.x.mcma...@oracle.com> > wrote: > > ... >> 4) AsyncConnection / Queue >> >> I find the term ‘block’ confusing here. It seems that the input channel, >> in the AsyncSSLDelegate implicitly puts itself into “blocking” mode >> when performing the initial handshake. The unblocking happens then >> after successful negotiation of ALPN. Maybe some term to indicate >> no higher-level callback? OR something else. > As far as Queue is concerned, it either works asynchronously or blocking. > If asynchronous then data is passed on through the callback. If blocking > then data has to be obtained by calling the blocking take() call. > > Within AsyncSSLDelegate, the handshake is then done in blocking mode > but when finished it switches to the async mode. > > Does that make it any clearer?
Thanks, it does. For my understanding … The Queue type is basically an unbounded blocking queue. Adding items will never block, since the queue can grow unbounded. Taking items will block when the queue becomes empty. There are methods to poll, and to push back items to the head. The queue also has a facility to register a context-free trigger / callback when an item is added to the queue. The callback has no knowledge of the queue or its internals, it just knows that an item has been added. How about block/unblock be renamed disable/enable [Put] Callback/Listener? I’m less sure what, if anything, AsyncConnection.unblock could be renamed to, since it has no knowledge of blocking or callbacks in the first place. I’m just trying to move away from the overloading of “block” in this context. -Chris.
