[concurrency-interest] We need to add blocking methods to CompletionStage!

Viktor Klang viktor.klang at gmail.com
Tue Sep 27 04:39:19 EDT 2016


Seems legit

-- 
Cheers,
√

On Sep 26, 2016 23:29, "Attila Szegedi" <szegedia at gmail.com> wrote:

> Not at all, you could just have a call to cancel() block until the future
> completes.
>
> *ducks*
>
> Attila.
>
> > On 25 Sep 2016, at 16:34, Viktor Klang <viktor.klang at gmail.com> wrote:
> >
> > If that truely is the case then the only way of implementing a readonly
> > Future is by throwing an exception from cancel...
> >
> > --
> > Cheers,
> > √
> >
> > On Sep 25, 2016 4:20 PM, "Joe Bowbeer" <joe.bowbeer at gmail.com> wrote:
> >
> >> This statement regarding what happens after cancel is called is correct:
> >>
> >> "*After this method returns, subsequent calls to **isDone**() will
> always
> >> return true*. Subsequent calls to isCancelled() will always return true
> >> if this method returned true."
> >>
> >> After cancel returns, the future is completed, hence isDone. If cancel
> >> returns true, i.e. it was cancelled, then  isCancelled returns true.
> But,
> >> for example if the future is already completed when cancel is called,
> then
> >> cancel will return false and isCancelled will return false.
> >>
> >> On Sep 25, 2016 6:49 AM, "David Holmes" <davidcholmes at aapt.net.au>
> wrote:
> >>
> >>> I think that was meant to read “After this method returns _*true*_,
> >>> subsequent calls …”
> >>>
> >>>
> >>>
> >>> David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160927/eb5412ba/attachment.html>


More information about the Concurrency-interest mailing list