Possible language changes

[Kevlin Henney]

In message <422B77AD.1030307 at cs.oswego.edu>, Doug Lea <dl at cs.oswego.edu> 
writes
>
>Only a couple of quick comments since I still think my opinion
>shouldn't count for much here..

I disagree :->

>> 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);

Sorry, I wasn't being clear. Yes, the capability exists, but as an 
extended feature. That is because Java started in a different place.

>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.

Yes, this is my feeling.

>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.

Definitely, but my issue for suggesting that cancellability is not 
initially in the core discussion is based on the variation in its 
implementation and interpretation, plus the amount of distracting 
disagreement that I have seen it generate, eg some of the discussions 
concerning a C++ mapping of Posix threading wrt cancellation. Very 
heated. But not productive.

My preference is to say that it would be a consideration, but its 
semantics would not necessarily be part of the core discussion. The 
minute you get drawn into that discussion without a solid base, it 
appears that (1) the rest of the good stuff is lost and (2) you have to 
spend more time discussing the core threading API that we are so 
studiously skirting around.

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

Yes, definitely useful, but if you want to sketch an API I was just 
again thinking of the things that would be considered less contentious 
and, therefore, more obviously acceptable.

Kevlin
-- 
____________________________________________________________

   Kevlin Henney                   phone:  +44 117 942 2990
   mailto:kevlin at curbralan.com     mobile: +44 7801 073 508
   http://www.curbralan.com        fax:    +44 870 052 2289
   Curbralan: Consultancy + Training + Development + Review
____________________________________________________________