NIO.2 and GC activity

[Alan Bateman]

Leon Finker wrote:
> :
>
> As for the cancelation, please correct me if I'm wrong, but I personally
> have not seen a single case when Cancel would be used by developers to
> cancel the recv/send requests on a socket. 
That is a fair comment.

> Usually the assumption is that
> closing the sockets cancels any pending requests. 
In this API then all outstanding I/O operations are required to fail 
with AsynchronousCloseException when the channel is closed.

> The asynchronous model
> lends itself to the following usage: schedule one or a few operations and
> get completion callback, then schedule more. If developers normally split up
> the data in fixed 2k/4k buffers, what would it mean to cancel the request?
> What if some of the buffers (that makes up a fully formed message) already
> went out... 
In the javadoc you will see that if cancellation cannot guarantee that 
bytes have not been transferred then it is required to put the channel 
into an error state that prevents further I/O operations from being 
initiated on that channel. This is specifically aimed at stream based 
connections where cancellation may leave the underlying connection or 
the channel is an inconsistent state.

>
> As for the context information recording the operation, it is possible for
> NIO2 API to take this context instead of returning new one each time. Then
> developers can reuse same context information per operation per connection.
>   
There are no plans to do anything like this at this time.

-Alan.