Salut,
David M. Lloyd wrote:
> On 12/16/2008 11:34 AM, Jeanfrancois Arcand wrote:
>> I would still think we need to manipulate Future and not specialized
>> IOFuture. Note that we started jsr 203 with IOFuture and we dropped
>> them to only use Future. I think this is more clearer...
>
> The problem with Future is that it is not suited to I/O operations. The
> "cancel" operation is intended to be invoked by someone who controls the
> target thread ("mayInterruptIfRunning"), and it is not clear whether
> this operation should block - the docs seem to imply that it does, so
> there's no way to asynchronously cancel an I/O task (which is silly -
> that's the whole use case of an async API!). Imagine a Swing app with a
> cancel button. If you click on the button and your cancel operation is
> blocking, the whole app is screwed unless you spawn the cancel off into
> another task.
>
> Also, j.u.c.Future doesn't have a built-in notion of callbacks - NIO.2
> has to bolt this on, which is sloppy in my opinion. And it limits you
> to only one CompletionNotifier.
Here you means CompletionHandler, right?
>
> And there's no way to ascertain whether the operation failed unless you do:
>
> try { future.get(); } catch (ExecutionException ex) { ..now unwrap
> and cast the cause, yuck.. }
But you can always get that information via your CompletionHandler IMO.
I do agree with you on the above uses case through...
>
> And there's no way to wait for completion *without* getting the result!
> There's also no way at all to wait uninterruptibly. You have to
> implement this yourself.
>
> This may be fine for regular tasks. But I've found it to be sorely
> inadequate for I/O purposes. People are using it because it's there,
> not because it's the right tool for the job. I think I/O is a big
> enough umbrella to merit its own interface. :-)
Fair enough :-) But I still do think we need to have a unified one
instead of several (or per operation). Now let me look at your links...
A+
-- Jeanfrancois
>
> - DML
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>