[concurrency-interest] Waiting for a cancelled Future

Viktor Klang viktor.klang at gmail.com
Fri Apr 22 03:22:41 EDT 2016


I prefer the model where execution control is separate from where the
result may be obtained. Those are two orthogonal concerns, and with
different access control (reading results vs writing the result)

-- 
Cheers,
√
On Apr 21, 2016 4:23 PM, "Millies, Sebastian" <
Sebastian.Millies at softwareag.com> wrote:

> I agree with Vladimir. Cancel says you don’t care about the result, so why
> should one wait for a task to produce something one doesn’t need?
>
> If a task cannot be cancelled gracefully, as you say, it should just
> refuse to be cancelled and do nothing in the cancel() method but return
> false.
>
>
>
> However, in case you really want it, couldn’t you do the following? Submit
> a task for execution that would release a Semaphore when it is finished.
> Produce a second future from the original one that would try to acquire
> that same semaphore before completing. Calling get() on that second future
> would block while the cancelled task is still running. Both parts of this
> approach could be encapsulated in a single utility method.
>
>
>
> n  Sebastian
>
>
>
>
>
> *From:* concurrency-interest-bounces at cs.oswego.edu [mailto:
> concurrency-interest-bounces at cs.oswego.edu] *On Behalf Of *Vladimir Ozerov
> *Sent:* Thursday, April 21, 2016 2:36 PM
> *To:* Daniel Tetlow
> *Cc:* concurrency-interest at cs.oswego.edu
> *Subject:* Re: [concurrency-interest] Waiting for a cancelled Future
>
>
>
> Hi Dan,
>
> This is an interesting question. Some frameworks which have their own
> "futures" has the same semantics as you described - they still wait for
> computation to complete. And both approaches could make sense.
>
> However, future.get() is essentially about result, not about thread or
> computation state. When future is cancelled, result is known immediately,
> and there is no reason to block waiters any further. So immediate return
> makes perfect sense to me in this case.
>
> Vladimir.
>
> 21 апр. 2016 г. 15:09 пользователь "Daniel Tetlow" <
> daniel.tetlow at optasense.com> написал:
>
> Hi,
>
>
>
> When I submit a task to one of the standard JDK ExecutorServices, I get a
> Future that represents the asynchronous execution of that task.
>
>
>
> If I cancel the task before it gets executed, then of course Future.get()
> returns immediately as there is no asynchronous execution to wait for.
>
>
>
> If I try to cancel the task while it is executing, what surprises me is
> that Future.get() still returns immediately even if the task is still
> actually running. So it appears that upon cancellation, the future becomes
> detached from the asynchronous execution state of the task. It may be that
> the task does not cancel gracefully, or that the task needs to do some
> cleanup on its cancellation path that takes time. In any case, if a task is
> executing by the time I cancel it, I’d still like to wait for it to finish
> before proceeding.
>
>
>
> I have tried putting my own execution status on the actual
> Runnable/Callable that I submit to the executor, so I can check that
> separately. But this seems wrong to me because I end up duplicating status
> already known by the FutureTask, and this is likely also prone to race
> conditions.
>
>
>
> How should I handle this, or am I doing something wrong to get into this
> state in the first place?
>
>
>
>
>
> Thanks for your comments,
>
>
>
> Dan.
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt,
> Germany – Registergericht/Commercial register: Darmstadt HRB 1562 -
> Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman),
> Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt; -
> Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas
> Bereczky - *http://www.softwareag.com* <http://www.softwareag.com>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160422/dfbf42aa/attachment.html>


More information about the Concurrency-interest mailing list