[concurrency-interest] Why does FutureTask hold reference to the Callable object forever?
Online at stolsvik.com
Thu Jan 24 18:25:16 EST 2008
Tim Peierls wrote:
> On Jan 24, 2008 5:18 AM, Endre Stølsvik <Online at stolsvik.com
> <mailto:Online at stolsvik.com>> wrote:
> Check decorateTask(...): please enlighten me on exactly HOW you're
> supposed to use those methods to really decorate your task, while
> still honoring the contract under which the Runnable/Callable was
> "Task" in decorateTask (and in AbstractExecutorService.newTaskFor)
> refers to the Runnable(Scheduled)Future, not to the submitted
> Runnable/Callable. These methods probably should have been named
> "decorateFuture" and "newFutureFor".
> The point of these methods is to give subclasses a chance to supply a
> different concrete type for the Runnable(Scheduled)Future returned when
> a Runnable/Callable is submitted.
This much is obvious from the method, and when you check the code for
STPE. However, you _have to_ make a wrapper that forwards all calls, as
you cannot yourself implement the actual needed behavior of the
RunnableScheduledFuture, since STPE's implementation of it,
ScheduledFutureTask, relies on the innards of STPE itself (and since you
aren't supplied with the arguments of the initial submit). At least it
seems so to me..
> I added an example to the wiki of using decorateTask to provide
> cancellation behavior in a custom scheduled executor service:
I tried using this feature (the decorateTask-methods) to implement
Exception-catching by wrapping and overriding run(), but didn't manage
to do it in any way (it hits me now that you could possibly proxy it and
use the reflection stuff to change visibility of some of those private
methods to make it possible to invoke them?).
But such amazing wizardry is not what those methods are meant to enable
you to do, then?
NB: Maybe put some @Overrides in that example code?
More information about the Concurrency-interest