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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!husc6!bloom-beacon!bu-cs!mirror!rayssd!raybed2!linus!dee
From: dee@linus.UUCP (David E. Emery)
Newsgroups: comp.lang.ada
Subject: re: Ada/UNIX
Message-ID: <43147@linus.UUCP>
Date: 20 Dec 88 14:31:56 GMT
Organization: The MITRE Corp., Bedford, MA
List-Id: <comp.lang.ada>

A bit more on this...  I read the Air Force report, and later spoke to
one of the authors.  The specific problem that they encountered
concerned the following: For a multitasking program running as a
single Unix process, Unix does NOT guarantee that I/O invoked by one
task does not block the entire process (i.e. all tasks).  In fact, in
the specific implementation, when one task did I/O, the process (all
tasks) did block.  It is well known in the Unix community that the
basic Unix I/O model calls for blocking.  There are some facilities
for non-blocking I/O in Unix, but they are mostly dependent on the
whims of the device driver writer.

Now many people have said, based on reading this report, that Ada and
Unix don't mix.  They are entitled to their opinions.  However,
blocking I/O is strictly a Unix limitation, Ada's tasking only makes
this limitation obvious to the user.  

In the specific application cited in the article, I understand that
the Unix compiler vendor developed a non-blocking I/O package that
would work on the specific hardware used by the Air Force.  This
solution was not general enough (because of Unix limitations, not Ada
limitations) to be turned into a product.

Incidently, I've been doing systems programming on Unix using Ada for
4 years now.  There are some issues/problems/shortcomings that you
have to address, but this is true of any language on any operating
system.  There are some things that aren't easy to do (try doing
multi-taskin in C on Unix, or in C on VMS...)

So, now you know "The rest of the story".

				dave emery
				emery@mitre.org (new style)
				emery@mitre-bedford.arpa (old style)
				linus!dee