On 07/13/2012 02:02 PM, Greg Wilkins wrote:
> On 14 July 2012 02:38, Scott Ferguson <ferg_at_caucho.com> wrote:
>> On 07/12/2012 06:26 PM, Greg Wilkins wrote:
>>> On 13 July 2012 09:25, Danny Coward <danny.coward_at_oracle.com> wrote:
>>> I think that both 1 and 2 can be provided as a layer above 3B.
>>
>> You can't really layer (2 nonblocking) above 3b (or 3a).
>>
>> It either requires buffering the entire message, or messy threading.
>
> Option 2 requires difficult threading decisions no matter what.
> When onMessage(InputStream message) is called, then the caller has to
> be prepared that this will be a long running call with the thread
> blocking as it calls read methods on the input stream. So the caller
> would be wise to dispatch a thread to do this.
>
>
> Option 2 over 3B is just moving that dispatch up a level.
No, it's not "just moving the dispatch up a level". As you point out,
Option 2 over 3B introduces an extra wake/unpark overhead for each
packet. (And probably an extra thread.)
> Hence while 2 may be a layer on top of 3B, it is probably a layer that
> should still be implemented within our API implementation, as it can
> be done more efficiently there and we don't expose nasty contracts to
> applications.
That's my point.
2 over 3B is not just a simple adapter layer. It's expensive.
(Related to threading efficiency issue is why I'd suggested a higher
level object (json) queue for reading and writing. Since the websocket
implementation already needs to deal with threading issues --
particularly with mux -- it's better positioned to handle the required
thread dispatch efficiently.)
-- Scott