[concurrency-interest] We need to add blocking methods to CompletionStage!
viktor.klang at gmail.com
Tue Sep 27 08:39:19 UTC 2016
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
> > 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
> >> 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.
> >> for example if the future is already completed when cancel is called,
> >> cancel will return false and isCancelled will return false.
> >> On Sep 25, 2016 6:49 AM, "David Holmes" <davidcholmes at aapt.net.au>
> >>> I think that was meant to read “After this method returns _*true*_,
> >>> subsequent calls …”
> >>> David
More information about the core-libs-dev