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

[Dávid Karnok]

If not a straight blocking method, a fluent conversion method to type R
could be useful IMO:

R to(Function<? super CompletionStage<T>, R> converter) {
    return converter.apply(this);
}

This way, who needs a blocking get can have a function prepared with a
blocking operation:

<T> Function<CompletionStage<T>, T> blockingGet() {
   cs -> {
       Object[] result = { null, null };
       CountDownLatch cdl = new CountDownLatch();
       cs.whenComplete((v, e) -> {
           if (e != null) {
              result[1] = e;
           } else {
              result[0] = v;
           }
           cdl.countDown();
       });

       try {
           cdl.await();
       } catch (InterruptedException ex) {
           throw new RuntimeException(ex);
       }

       if (result[1] != null) {
          throw new RuntimeException(result[1]);
       }
       return result[0];
   }
}

T t = cs.to(blockingGet());


while others can convert it to a more enabled dataflow system:

cs.to(Flux::fromFuture)
.filter(v -> v < 50)
.defaultIfEmpty(-10)
.subscribe(System.out::println, Throwable::printStackTrace);

2016-09-27 10:39 GMT+02:00 Viktor Klang <viktor.klang at gmail.com>:

> 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
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Best regards,
David Karnok