[concurrency-interest]yet another proposal for Executor

David Holmes dholmes@dltech.com.au
Thu, 7 Feb 2002 10:43:54 +1000

> the person implementing cancel() for some Callable should write it so that
> it can be called at any time.

A further clarification - you don't really mean "any time" in the sense that
cancel() and call() could be executing concurrently do you? Rather it will
turn out that cancel() with either be invoked before call() is executed, or
after call() has been "terminated" ??

> class MyCallable implements Callable {
>    Object handle_ = null;
>    Object result_ = null;
>    Object call() {
>       handle_ = get_request_handle(...); // won't block
>       try {result_ = wait_handle(handle_);} // might block,
> assume non null return
>       catch (InterruptedException e) {
>           System.out.println("i've been interruted");
>          throw e;
>       }
>    }

I know this is only an example and not necessarily representative of the
general case, but even assuming you can cancel a request, why bother with
the cancel function - why not do the cleanup in the catch clause? That was
my point in the earlier email - the only way you ever get cancelled is by
the throwing of an exception, which you can always catch and then perform
cleanup. Further, the catch clause is more likely to have all the context
you need to do a proper cleanup - without having to store it in fields.

David Holmes