[concurrency-interest] Future.isCompletedNormally Future.isCompletedAbnormally

joe.bowbeer at gmail.com joe.bowbeer at gmail.com
Thu Mar 5 01:08:07 EST 2015


To clarify my position: These methods would be fine if the default implementations were not so complicated (aka heavyweight, and prone to failure when applied to custom Future implementations).

However, I doubt that a better implementation is possible without introducing a sibling of get() to support this kind of use.





—
Sent from Mailbox

On Wed, Mar 4, 2015 at 9:50 PM, Martin Buchholz <martinrb at google.com>
wrote:

> On Wed, Mar 4, 2015 at 9:23 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>> What's the motivation for doing that? Why moving this up in the hierarchy
>> is desired? These methods seem like utilities one would write on top of
>> their own concrete implementations.
>>
> The motivation is "if these methods make sense for ForkJoinTask, then they
> make sense for all Futures".
>> Also, what's the purpose of the labeled loop? Moreover, what if get () on
>> that impl always throws interrupted exception - this loops forever? I guess
>> I don't like this because it makes assumptions about how the implementation
>> behaves in get ().
>>
> Let's first decide whether we want these methods before fixing esoteric
> bugs (throwing InterruptedException without clearing the interrupt status,
> really?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150304/52b2598e/attachment.html>


More information about the Concurrency-interest mailing list