Re: How Ada could have prevented the Red Code distributed denial of service attack.

[James Rogers <jimmaureenrogers@worldnet.att.net>]

Kaz Kylheku wrote:
> 
> Achieving things in languages is sometimes just paperwork. It wouldn't
> take much to define some standard C++ library for multithreading. The
> difficulty lies in implementations.
> 
> If you add difficult things into languages, two things happen.
> They get implemented less, or sometimes they get implemented
> incompletely.
> 
> We see this with C++: poor support for templates here and there, lack of
> support for exception handling here and there.

Ada has gone through two standardizations (1983 and 1995). 
Concurrency has been in the language since the first standard.
The new standard did add capabilities to the Ada concurrency model,
fixing a tendency towards race conditions, and adding a cleaner
approach to asynchronous communications. 

Ada has also had generics and exceptions since the first standard.
Every Ada compiler in the market place implements all these features.

This does not mean that the features are easier in Ada. It might
mean that the Ada standard is better written than the C++ standard.
I cannot testify to that issue, not being a compiler writer myself.

> Some things should be left to the open market, at least for a while.
> C++ was only standardized in 1998 for the first time. Thus far,
> there hasn't emerged a *de facto* standard library for multithreading
> that could serve as a candidate for becoming standard. So the
> C++ committee will perhaps have to invent one, (assuming they want to
> add multithreading).

Standardization is a very formal process. New features may be
influenced by the open market. On the other hand, they are also
often influenced by careful research and a clearly stated set of
requirements.

Market forces are not always as clear as some would like to believe.
For instance, are the Microsoft tools driven by the market, or do
they drive the market? Comments by others in this thread seem to
indicate they drive at least a large portion of the market. Allowing
language features to be "driven by the open market" seems to be
nothing more than letting the dominant players control the language.
Sometimes this may be good. Other times it clearly is not.

> The problem with multithreading is that there are so many ways to hack it
> on a given platform. If you have standard threading, but C++
> implementors cop out with lame implementations, nobody will want to
> use it.  Or they will use it, but programs will only work well on a few
> quality implementations, in essence rendering the standard threading
> portable only on paper.

The same argument could be made about programming in general.
There are so many ways to hack it on a given platform. If you
standardize a language implementers will cop out with lame
implementations nobody will want to use. Is this your experience
with C++ since standardization? I hope not.

> Any decent C++ threading will have to interoperate nicely with a
> platform's ``native'' threading, because real-world C++ programs are
> rarely developed in a vacuum. People will do things like create threads
> using some platform-specific mechanism, and have it execute parts of
> the C++ program along side C++ threads --- kind of hard to avoid,
> for instance, if using some third party library which wants to invoke
> callbacks in your program, using its own threads.

Just as any decent C++ implementation will have to interoperate nicely
with a platform's other "native" operating system features. There is no
reason to isolate threading as a special case.

Jim Rogers
Colorado Springs, Colorado USA