AsynchronousSocketChannel.shutdownInput()

[Alexander Libman]

> >
>
> The problem is that write() returns the number of bytes written.
> shutdownOutput() would only make sense if it returned an Integer (indicate
> the number of bytes written) instead of returning the channel.


write() must return the  number of elements (chars, not bytes!) processed
from the buffer(CharBuffer), i.e. consumed by encoder.
How many bytes encoder produces on output(i.e. on internal channel ) is not
important for the caller.
"write () "is a job and  "completed()" callback means the job is done.
If write() completed with less bytes processed than requested, it should be
called again.
write() in TCP means data accepted for the trasnmission, but it does not
mean data is delivered.
It is up to decoder to buffer encoded data or to push them into internal
channel.
So shutdownOutput() works like flush and prohibits any future write
operations.
If error occurs during shutdownOutput() , exception should be thrown.
If you are still worried about all data are transmitted on internal channel,
you can wait in external channel close()  the completion of all operations
on internal channel.


>
>
> Alexander Libman wrote:
> >
> > Also there are  some cases (not very often) when  the closure
> of external
> > channel (filter itself) should not close
> > the embedded(internal) channel. Assume we want to write
> > AsynchronousSMTPClient.
> > It can be implemented  via the following stack of asynch. filters:
> > AsynchronousByteChannel
> >            |
> > AsynchronousCharChannel
> >            |
> > AsynchronousSMTPChannel
> >
> > AsychronousSMTPChannel "rents"  the underline channels to do a SMTP
> > transaction:
> > MailFrom, RcptTo,..., Body
> >
> > After transactions is completed successfully, SMTP channel can
> be closed,
> > but
> > AsynchronousCharChannel can be reused for the next SMTP transaction.
> >
>
> Interesting point. Perhaps there should be a configuration option that
> indicates whether close() is recursive?

May be some flag :
close (boolean doNotCloseInternalChannel)
and
close ()  by default is implemented as
{ close (false);}

or more generic closeWithOptions(...)
to specify:
a) close or nor the internal channel
b) wait to all operations on internal channel to be completed()

>
> >
>
> I like the idea of collaborating on this work and the idea of moving
> readLine() into AsynchronousScanner, but I'm afraid that the last time I
> took a look at your framework I was a little put off by the lack of
> source-code comments and Javadoc.

Yes, I know - it is still  a draft, but it is working draft and I hope  the
code is not hard to read.
We will definetely try to find time to write better comments/doc.
Alex