Scatter / gather

[Rémy Maucherat <re...@apache.org>]

Hi (Mark - nobody else will care I suppose),

Since the SocketWrapperBase has been neatly factored away, I think scatter
gather NIO2 style calls should be added to it for future use.

-     public <A> void write(ByteBuffer[] srcs, int offset, int length,
            long timeout, TimeUnit unit, A attachment,
            CompletionHandler<Long,? super A> handler)
The main semantic difference with real NIO2 would be that it will write ALL
the content instead of some of it and let people deal with it for no good
reason (thanks ...).
- Scatter would be new since the NIO2 connector Nio2Channel doesn't have it
at the moment, its goal is to avoid additional parsing for protocols which
use fixed lengths for some of their fields (this should be the case); it is
probably less useful than gather though
    public abstract <A> void read(ByteBuffer[] dsts,
                                  int offset,
                                  int length,
                                  long timeout,
                                  TimeUnit unit,
                                  A attachment,
                                  CompletionHandler<Long,? super A>
handler);
To help protocol implementation even more, maybe it would be possible to
add an extra parameter to specify a minimum amount of bytes read, or
(better) some additional interface to check if more bytes should be read
before calling the completion handler

I'm not sure how useful it is to also add the other simpler read/write
method variants or the future styled ones, I'd say it is useless though. At
first the new calls could be added to Nio2SocketWrapper before getting
pulled up once the two others implement it.

Comments ?

Rémy

Re: Scatter / gather

[Rémy Maucherat <re...@apache.org>]

2015-03-06 16:49 GMT+01:00 Mark Thomas <ma...@apache.org>:

> I can see how both might be useful. No objections here.
>
> So in addition to my initial plan, I added some state information (NIO2
thinks it is a good idea to hide it), as well as flexibility for the
completion handler call (NIO2 calls it as soon as it read or wrote
anything, leading in most cases to boilerplate code to handle incomplete
operations).

There's also no internal buffering and added sync since the caller should
use what it needs there, the idea is to preparse the protocol in the IO on
read and avoid dumb buffering copies on write. OTOH, with encryption the
benefits go away to some extent (the NIO2 SSL would be improved though,
it's not really representative at the moment) and the "test" will be if
this is useful for HTTP/2. In that case it could be generalized, otherwise
there will be no point keeping it.

Rémy

Re: Scatter / gather

[Mark Thomas <ma...@apache.org>]

On 06/03/2015 15:14, Rémy Maucherat wrote:
> Hi (Mark - nobody else will care I suppose),
> 
> Since the SocketWrapperBase has been neatly factored away, I think scatter
> gather NIO2 style calls should be added to it for future use.
> 
> -     public <A> void write(ByteBuffer[] srcs, int offset, int length,
>             long timeout, TimeUnit unit, A attachment,
>             CompletionHandler<Long,? super A> handler)
> The main semantic difference with real NIO2 would be that it will write ALL
> the content instead of some of it and let people deal with it for no good
> reason (thanks ...).
> - Scatter would be new since the NIO2 connector Nio2Channel doesn't have it
> at the moment, its goal is to avoid additional parsing for protocols which
> use fixed lengths for some of their fields (this should be the case); it is
> probably less useful than gather though
>     public abstract <A> void read(ByteBuffer[] dsts,
>                                   int offset,
>                                   int length,
>                                   long timeout,
>                                   TimeUnit unit,
>                                   A attachment,
>                                   CompletionHandler<Long,? super A>
> handler);
> To help protocol implementation even more, maybe it would be possible to
> add an extra parameter to specify a minimum amount of bytes read, or
> (better) some additional interface to check if more bytes should be read
> before calling the completion handler
> 
> I'm not sure how useful it is to also add the other simpler read/write
> method variants or the future styled ones, I'd say it is useless though. At
> first the new calls could be added to Nio2SocketWrapper before getting
> pulled up once the two others implement it.
> 
> Comments ?

I can see how both might be useful. No objections here.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org