AsynchrronousByteChannel vs AsynchronousFileChannel andAsynchronousTransmitter

[Alan Bateman]

Alexander Libman wrote:
> :
> Agree. Basically the question was what was the better solution:
> add to the AsynchronousFileChannel some extra features or
> to develop a small wrapper like AsynchronousByteFileChannel (may be you can
> advise the better name).
> Seems, the time spent on writing AsynchronousByteFileChannel was not wasted
> :)
>   
Given that the usage differs a bit from the intended usage then this 
seems more appropriate for a utility library or method. You might not 
need to define a class name but instead have a static method that 
returns an adapter, maybe:

static AsynchronousByteChannel newChannel(AsynchronousFileChannel ch) { 
... }

> :
> It is not a problem to support single position for the
> AsynchrnousByteFileChannel.
> The choice of two independent read and write positions was made
> deliberately.
> It allows to think about file as two independent streams - one for reading,
> another for writing.
> It also very convinient for the model
> read-updateInPlace-writeOnSamePosition.
> Another reason is : since a position can be updated only on inner
> AsychrnousFileChannel's operation completion,
> two positions will make possible to support one outstanding read and one
> outstanding write simultaneously.
> If you think that one position is better solution, then  it is also good:
> the developer can create two "AsynchrnousByteFileChannels" and
> use one for reading and second for writing. What is the preferred solution,
> I do not know yet too.
> Yes, need to experiment more.
>   
I don't have a strong opinion on this except to say that different 
global positions for reading and writing is likely to be a surprise to 
many developers.

> :
> For this pure Java solution we do not have to specify thread pool.
> After initiation of the first read, Transmitter initiates next operations
> from the completion handler for the previous operation.
> So it works in both thread pools: for source and destination.
>   
It it possible that the source and target channel are associated with 
different group and hence there would be problems with thread identity 
if you don't specify who will call the completion handler. It's an 
interesting question to think about.

> :
>
> We need our own thread pool in two cases when we deal with filters and
> artificial asynchornous objects like Transmitter:
> a) when a completion handler's execution takes a long time ( SSLEngine has a
> task to run, etc)
> or
> b) when an operation started on outer channel has immediate completion
> without any actions performed on inner channel.
>   
Right, and for that we'll need to come back to that request to submit 
tasks to the group's thread pool. Rémi also asked recently about getting 
a reference the group.

> :
> This would be nice. Here we may need to specify which thread pool to use:
> source or destination.
> For Windows such "transferFrom" obviously can be mapped to
> TransmitFile/TransmitPackets
>   
FWIW, we haven't been able to use this in NIO to date because of 
semantic issues. Specifically, these Win32 calls are designed to be the 
sole writer to the socket and there are cases where they bypass the 
socket buffer. It's a while since we have looked at them though.

-Alan.