[concurrency-interest]yet another proposal for Executor

David Holmes dholmes@dltech.com.au
Thu, 7 Feb 2002 11:29:48 +1000

> The reason i want to offer at least the option for concurrent cancel
> (even if that isn't the default behavior) is that i have already
> experienced several cases where that is exactly what i want.
> for example, i might want cancel() to close a socket in order to dislodge
> my run() or call().

Okay but that conflicts with the definition of cancel() as a cleanup
function. I'm just trying to get clear on the API here - causing
cancellation and cleaning up after cancellation are two different things in
my book. I agree that with the current limitations of Thread.interrupt, and
the fact that interrupt will never know about some API's, then a cancel()
method is the only reasonable place to put the code that can figure out
exactly how this task needs to be cancelled. Then, provided the API's you
are using make cancellation visible (which they should) the actual cleanup
of cancellation could either by done inline (eg in a catch clause) or via a
separate handler. The handler would either be invoked as a second part of
the cancel() function (but watch out as you may not know exactly what state
your call() is in) or in response to the executor catching the
"cancellation" exception.

David Holmes