AsynchronousFileChannel.transferTo?

[Benedict Elliott Smith]

Hi Remi,

I assume that you're describing a service that performs x synchronous
transferTo operations concurrently using an ExecutorService? If so, it
isn't really what I'm looking for, as I may want to support a very large
number of concurrent I/O operations. If not, and you actually have a
working implementation of threadless asynchronous copies, I'd be very
interested.


On 3 December 2011 17:25, Remi Forax <forax at univ-mlv.fr> wrote:

> I've written something like this.
> An asynchronous copy that returns a Future.
>
> I can provide the code if you want.
>
> Rémi
>
>
> Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> >On 02/12/2011 19:45, Benedict Elliott Smith wrote:
> >> Hi,
> >>
> >> I just made the fairly rookie error of assuming that
> >> AsynchronousFileChannel would have an analagous method to
> >> FileChannel.transferTo, but unfortunately this appears not to be the
> case.
> >>
> >> Is this simply due to a lack of time, or is there some reason why it
> >> cannot be incorporated? I have lots of disk to network transfers to
> >> perform, and I'd rather not spawn a thread for each, but I'd equally
> >> rather not copy the data into a buffer and straight back out again;
> >> I'd prefer for the transfer to be straight DMA, with a callback
> >> letting me know it happened.
> >>
> >> Are there any plans for this to be supported at any point in the
> >> future? Or am I being completely retarded and simply missing the
> >> already present functionality? I've searched the obvious places for
> >> information but so far no luck, and no discussion of it I could find
> >> on the mailing lists.
> >>
> >> Any light you can shed would be appreciated...
> >>
> >> Cheers,
> >Yes, just lack of time and clearly desirable to be have an asynchronous
> >transferTo method. The interesting question is whether the target
> >channel (or source in the case of a transferFrom) is a synchronous or
> >asynchronous socket channel. For now I'm not aware of anyone working on
> >adding this but clearly something desirable to add at some point.
> >
> >-Alan
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111205/d85bd8fa/attachment.html