Possible language changes

[Boehm, Hans]

> 
> Boehm, Hans wrote:
> > I agree with Doug.  But I think it would be much harder still to 
> > standardize the higher layers in C++, since we have such a 
> diverse set 
> > of existing interfaces, some of which are very heavily used:
> > 
>  > ...
> 
> I believe that all of these at least have some basic notion
> of a thread.
> 
I think that OpenMP doesn't, at least not one that can be abstracted
in the way we're discussing.  If I understand correctly, the threads
are effectively created with 

#pragma omp parallel

(See http://www.openmp.org/drupal/mp-documents/cspec20.pdf )

If your goal is to design the language so that the same code can
be executed as sequential code by a system that doesn't understand
threads, then this seems to be a reasonable design choice.

We could still ignore it.  On the other hand, it's a widely used
system, which seems to be supported by most vendor compiler, which
has an open source implementation, and which seems to share the
problems we're addressing.

What's the problem we're trying to address here?  Is it purely a
specification issue in that it seems strange to talk about
threads without having a defined way of introducing them?
If so, does it make more sense to cast this as defining something
like a "futures" library package, which gives you access to
concurrency, but doesn't really claim to be anyone's basic threads
library?

Otherwise, I continue to worry that we are merely adding the
(N+1)st mechanism, which seems unlikely to dominate soon because:

-Microsoft already has their own, which will probably perform
better if you only care about that platform.

-The rest of us already have code written using pthreads, Boost, NSPR,
Ace, and have no good reason to change, especially since

-Converting to the new standard raises all sorts of interoperability
issues with libraries still using the "old" stuff, including C
interoperability issues.

In the Java world, JSR 166 had the big advantage that it was
extending an existing single threads interface.  We're "extending"
a dozen, I think.

Hans