hg: nio/nio/jdk: First installation of potential updates for M4

[Alexander Libman]

Ok,
Basically we defer real cancellation till closure.
Keeping in mind that cancel() is accessible only from Future<> form
and rule "reuse buffers after close" is applied only for cancellations and
timeouts -
all this works for me.
Thank you,
Alex

> -----Original Message-----
> From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM]
> Sent: Monday, May 18, 2009 4:54 AM
> To: Alexander Libman
> Cc: nio-dev at openjdk.java.net
> Subject: Re: hg: nio/nio/jdk: First installation of potential
> updates for M4
>
>
> Alexander Libman wrote:
> >> No, it shouldn't interfere with other I/O operations. For example on a
> >> channel to a stream socket then you might cancel a read and this should
> >> not interfere with a concurrent write. In this case the cancel may not
> >> be able to guarantee that bytes have not been transferred so this will
> >> prevent further reads on the channel (but it should not impact
> writing).
> >>
> >>
> >
> > Very clear.  May be couple lines from above paragraph would be
> nice to see
> > in javadoc.
> >
> OK,  I'll see if I can add wording to make this clearer.
>
> > :
> > I was thinking about such solution earlier. It will work fine
> only with one
> > condition:
> > user must discard buffers used in cancelled operation.
> > I wanted avoid discarding buffers  and provide the following
> guarantee at
> > least in filters:
> > If a completion is delivered (exception/result  or  the moment
> of invocation
> > the completion handler), then
> > the developer can reuse buffers for the finished operation.
> >
> There is a paragraph in the cancellation section that recommends that
> the buffers be discarded or "care taken to ensure that the buffers are
> not accessed while the channel remains open". Cancellation will be
> rarely used, if ever, so either approach should be okay. On the other
> hand, cancellation will be frequently used as timeouts in
> AsynchronousSocketChannel. In that case the I/O operation will fail with
> InterrupedByTimeoutException. If the application decides not to close
> the channel immediately then it will need to discard the buffer or
> ensure that it doesn't re-use it until the channel is closed. The
> timeout case might not be a concern for your filters package.
>
> > :
> > If discarding buffers is required only for cancelled operations
> and not for
> > all other failures, I would be also OK.
> >
> Cancellation and timeouts (which is essentially a type of cancellation)
> are the only two cases where you must take care not to access the
> buffers until the channel is closed.
>
>
> > Good. I asked because it allows to implement non-cancellable  cancel()
> > without discarding buffers in form
> >
> > cancel (boolean mayInterruptIfRunning)
> > {
> >     if (! mayInterruptIfRunning) {
> >          try  {
> >               this.get();
> >          }
> >          catch (Exception e)
> >          {}
> >
> >          return isCancelled();  // actually always returns false
> >     }
> >     ....
> > }
> >
> My understanding is that Future#cancel was not intended to block
> indefinitely like this (it can't throw InterruptedException for
> example). Since cancel can't do anything in this case it should be fine
> to just return true (assuming it hasn't already completed or cancelled)
> as the application is saying that it is no longer interested in
> the result.
>
> -Alan.
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.339 / Virus Database: 270.12.34/2121 - Release Date:
> 05/18/09 17:55:00
>