Hi Chris.
On 27/04/2017, 18:56, Chris Hegarty wrote:
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.
Right. The producing side never blocks. The consuming side works either
through a callback or from a blocking take.
How about block/unblock be renamed disable/enable [Put] Callback/Listener?
Ok, how about enable/disable Callback?
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.
It would have to be enableCallback() from above. AsyncConnection does define
the callback API as well though.
Thanks,
Michael
I’m just trying to move away from the overloading of “block” in this context.
-Chris.
