The CompletionHandler<V,A> Interface in Asynchronous context
向雅
fyaoxy at gmail.com
Thu Nov 12 05:57:12 PST 2009
I mean add the additional completed method for EOF, and only for EOF.
for example in WindowsAsynchronousSocketChannelImpl$ReadTask
run(){...
487 line:
// initiate read
int n = read0(handle, numBufs, readBufferArray, overlapped);
if (n == IOStatus.UNAVAILABLE) {
// I/O is pending
pending = true;
return;
}
if (n == IOStatus.EOF) {
-->At this point, we already check the EOF, so let call the
completed(attachment) rather than the completed(result, attachment)
method. we can still use CompletionHandler interface, also can check
and use ReadCompletionHandler interface. If use ReadCompletionHandler,
so the client code no need do result==-1? check.
// input shutdown
enableReading();
if (scatteringRead) {
result.setResult((V)Long.valueOf(-1L));
} else {
result.setResult((V)Integer.valueOf(-1));
}
} else {
throw new InternalError("Read completed immediately");
}catch(...)
525 line: // invoke completion handler
Invoker.invoke(result);--> At here, call completed(result,
attachment) method.
}
致敬
向雅
2009/11/12 Alan Bateman <Alan.Bateman at sun.com>:
> 向雅 wrote:
>>
>> :
>> No:)
>> I mainly mean I dont think it as a great way that all code write
>> result ==-1? check.
>> Everybody do the check, Everybody run the check, some waste:)
>> some like the // signs case in protocol url.
>> so the additional method out.
>>
>> About the bytecount read not report, look-seems I ever got. And I run
>> again some test, not found unreport case.
>> from the code, I found:
>> my complete method have a comment:
>> if (result == -1) {
>> // ONLY happen the channel closed by remote server
>> close();
>> return;
>> }
>> but my version repository tell me, in the close() method, I do later
>> add the buffer data check.
>>
>>
>
> I don't think I understand your proposal - the server/application needs to
> know about EOF but it looks like your ReadCompletionHandler.completed it not
> invoked when EOF is reached.
>
> -Alan.
>
>
More information about the nio-dev
mailing list