From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-08 05:26:30 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.stealth.net!204.127.161.2.MISMATCH!wn2feed!worldnet.att.net!135.173.83.71!wnfilter1!worldnet-localpost!bgtnsc06-news.ops.worldnet.att.net.POSTED!not-for-mail Message-ID: <3B713077.70315C0F@worldnet.att.net> From: James Rogers X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c++ Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <3b6a453c.1193942215@news.worldonline.nl> <9keejl$fhj@augusta.math.psu.edu> <3c30da40.0108060848.796d9bd9@posting.google.com> <3B6F3216.F410BBFF@home.com> <3B6F3FAE.B9B9FFCF@globetrotter.qc.ca> <3B6F5BB2.A879B933@worldnet.att.net> <3B7077A3.77D2BBE5@globetrotter.qc.ca> <3B70C621.DC9A8F35@worldnet.att.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 12:26:08 GMT NNTP-Posting-Host: 12.74.161.243 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc06-news.ops.worldnet.att.net 997273568 12.74.161.243 (Wed, 08 Aug 2001 12:26:08 GMT) NNTP-Posting-Date: Wed, 08 Aug 2001 12:26:08 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:11605 comp.lang.c++:80933 Date: 2001-08-08T12:26:08+00:00 List-Id: 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