Re: 答复: 答复: (fc) FileChannel.transferFrom/transferFromArbitraryChannel to return -1 at some error condition

[Alan Bateman]

On 30/01/2021 07:52, lihuaming (A) wrote:
>
> ### if the arbitrary channel was just closed by peer side, 
> transferFrom will return 0 this time or next time, and there is no way 
> for it knows that the underlying socket was closed, unless it calls 
> channel.read. But for performance consideration, I think some 
> framework/program would like to call FileChannel,transferFrom(channel, 
> …) only, rather than followed by a read+write just in case of channel 
> is closed by peer side; read+write can be optimized by only do it if 
> transferFrom(channel, …) returns 0, but it still has some extra cost, 
> and code is not simple and straight.
>
> ### I don’t think this is jdk bug and I do have concern about the 
> compatibility too and explained to framework/program developers, but I 
> can also understand their points, so want to see if there are some way 
> to make it more friendly to framework/program developers in this 
> situation. Hope I have made it clear J. If there is no other better 
> solutions, I will let them know that it’s better to modify their code.
>
> Thanks Alan for discussion.
>
>
Right, I think you get it. In this case the framework will need to fix 
their code.

While not the case here, I do have sympathy for those trying to using 
this API with a source channel that is configured non-blocking. As the 
method returns the number of bytes transferred (meaning read and then 
the written to the file) then it can't distinguish the EOF from the "no 
bytes available" case. This is probably something we should put into an 
@apiNote.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210130/c11babf9/attachment.htm>