[concurrency-interest]yet another proposal for Executor

Mark D. Anderson mda@discerning.com
Wed, 6 Feb 2002 19:50:44 -0800


> Okay but that conflicts with the definition of cancel() as a cleanup
> function. 

well, "cleanup" could be used to describe either situation, but i do agree
that it would probably be clearer to have different functions for the different
states. 

so we could have cancel() which is only to be called when in the queued stated,
and call() has not yet been called().
people might still program defensively, but the intent is that an Executor would
only call it from an unqueue() operation, which will only succeed on a task not
yet started.

we could have the other hook function, to be called concurrently while something is running,
an abort(). This function could do something severe such as closing its own socket,
or something lighter like setting a bit which might be checked in its call() function.

so then the table would be:
state             Executor method        Callable method
QUEUED        unqueue()           cancel()
RUNNING     interrupt()           abort()

another idea would be to call them the same thing, perhaps:
state             Executor method        Callable method
QUEUED        unqueue()           handleUnqueue()
RUNNING     stop()           handleStop()

-mda