Possible language changes

[Doug Lea]

Only a couple of quick comments since I still think my opinion
shouldn't count for much here..


> Regardless of what names are chosen for the concepts (Executor vs 
> Threader, Threadable vs Runnable) or the concrete implementations 
> provided by a library, one difference in the interface I would
> consider, based on the model I outlined, is that an Executor return a
> future. This more closely follows the notion of threads as
> asynchronous functions in C++. There is no direct equivalent to this
> in Java.
> 

This form is called "submit" in ExecutorService:

    <T> Future<T> submit(Callable<T> task);
    <T> Future<T> submit(Runnable task, T result);
    Future<?> submit(Runnable task);

We split it up this way for a combination of two reasons:
   1) Some people do not want the overhead of a Future object
      when running a task using Executor.execute.
      (Many concurrent Java programmers
      are more obsessive about performance than C++ programmers!
      So this stuff runs fast. In an absolute sense, not just a Java
      sense :-)

   2) ExecutorServices (but not plain Executors) have a notion
      of shutting down, so can deal with cancellation etc of
      Futures while shutting down. (Internally, there is a coupling
      of concrete ExecutorService classes and concrete Future
      classes.)

It would have been a simpler design all around to have absorbed
together Executor and ExecutorService, but pressures like these
led us to separate the bare-bones Executor from the ExecutorServices
that almost everyone actually uses. Maybe something else would
work better in C++ though.

> public interface Future<V> { 
 > boolean cancel(boolean mayInterruptIfRunning);
> 
> However, I would tend to something more minimal at the moment: omit
> cancellability and time-out handling for the moment. The former
> because it is a minefield that often sidetracks constructive 
> discussion on threading as a whole and the latter because there is a 
> notional dependency on any other date-time facilities that could be 
> introduced.

We found that a LOT of people want cancellability. The API is
a bit of a compromise -- "cancel" is allowed to return false for
any reason, meaning that you couldn't cancel, so caller must
somehow cope. And its mayInterruptIfRunning arg is just a hint,
not a mandate to asynchronously cancel. People seem to be able
to live with this.

I agree that timeouts might be too painful to deal with in C++,
but again, a lot of people use them in java versions.

-Doug