[concurrency-interest]yet another proposal for Executor

Mark D. Anderson mda@discerning.com
Wed, 6 Feb 2002 17:17:51 -0800

> > 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" ??

actually, i did mean concurrent.

in my prototype, cancel() is called both from Executor interrupt() (in the
middle of a call), or from Executor unqueue() (before a call).
That policy should probably be configurable when an Executor is created
or when Executor interrupt() is called, because you are correct that the person implementing
the Callable may not want cancel() called concurrently.

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(). Or I might have some other api that supports asynchronous
cancel (some database apis support asynchronous cancel from another thread
as one of the few operations that can be done concurrently on a statement handle).