Newsgroups: comp.lang.smalltalk,comp.lang.scheme,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!hudson.lm.com!netline-fddi.jpl.nasa.gov!elroy.jpl.nasa.gov!lll-winken.llnl.gov!sol.ctr.columbia.edu!howland.reston.ans.net!ix.netcom.com!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: Multithreading
Message-ID: <hbakerCzFJG2.HJ7@netcom.com>
Organization: nil
References: <GWYANT.94Nov10133254@cloyd.east.sun.com> <hbakerCz44Jp.H8y@netcom.com> <3ag8ga$cvc@wcap.centerline.com>
Date: Thu, 17 Nov 1994 20:55:14 GMT
Lines: 52
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:18083 comp.lang.scheme:11342 comp.lang.lisp:15678

In article <3ag8ga$cvc@wcap.centerline.com> chase@centerline.com (David Chase) writes:
>gwyant@cloyd.east.sun.com (Geoffrey Wyant - Sun Microsystems Labs BOS) writes:
>> >Anyone interested in high-quality next-generation systems/applications 
>> >languages should take a hard look at Modula-3 and the DEC Systems Research
>> >Center implementation mentioned above !
>
>hbaker@netcom.com (Henry G. Baker) writes:
>> This is all pretty interesting, since I have been told that the most
>> obvious example of an Ada which _doesn't_ do threads correctly with
>> respect to I/O is _DEC_ VAX Ada.  Either they learned from their Ada
>> experience or they sand-bagged the Ada product to make Modula look
>> good.
>
>This must have been written by some crank masquerading as
>Henry Baker, who is (to my knowledge) a sensible guy who
>wouldn't pay much attention to such a nutty conspiracy theory.
>Obviously, the people working in DEC's research labs are
>different from the people working in DEC's product labs.  

This is the same guy, but in a cranky mood. :-)

I'm cranky because the good stuff never seems to make it from the
laboratory to the marketplace, and the dreck products never seem to
improve, except in directions that never solve their fundamental
problems.

Why didn't the DEC Modula people first fix the Ada product, which was
actually selling moderately well at one point?  I would imagine that
the same basic mechanism that was used in the Modula system could have
also been used by the Ada system.

In my experience with mainframes from the 1960's and early 1970's, the
primary purpose of multiple threads at that time was to allow
asynchronous I/O.  In reading the original Ada specifications, it was
clear (to me, at least) that this use of threads was contemplated,
although for some reason that I can't fathom, the standard Ada I/O
package is synchronous.

From what I've been told about DEC's VMS system, it was more conducive
to implementing threads in Ada correctly than Unix was, because Unix
I/O was almost terminally synchronous.

Perhaps DEC's Ada people concluded from the fact that the Ada standard
I/O package offered only synchronous I/O that it was ok to stop all
other processing during I/O.  Perhaps it never occured to them that
people might want to use Ada's multiple threads to _emulate_
asynchronous I/O.

      Henry Baker
      Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.
      Contact hoodr@netcom.com if you have trouble ftping

