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
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,18385551e0d37b37
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-11-03 12:06:56 PST
Path: 
 bga.com!news.sprintlink.net!hookup!news.mathworks.com!news.kei.com!world!blanket.mitre.org!linus.mitre.org!linus!mbunix!eachus
From: eachus@spectre.mitre.org (Robert I. Eachus)
Newsgroups: comp.lang.ada
Subject: Re: Ada replacements for DOS I/O
Date: 2 Nov 94 15:20:33
Organization: The Mitre Corp., Bedford, MA.
Distribution: world
Message-ID: <EACHUS.94Nov2152033@spectre.mitre.org>
References: <44279.cwarwick@fox.nstn.ns.ca> <38qq4u$as2@theopolis.orl.mmc.com>
NNTP-Posting-Host: spectre.mitre.org
In-reply-to: dennison@romulus23.DAB.GE.COM's message of 28 Oct 1994 12:17:34
 GMT
Date: 1994-11-02T15:20:33+00:00
List-Id: <comp.lang.ada>

In article <38qq4u$as2@theopolis.orl.mmc.com> dennison@romulus23.DAB.GE.COM (Ted Dennison) writes:

 > Don't be so hard on Alsys (at least not for this). I know of NO Ada system
 > on any platform that handles tasks and I/O that well. VAX Ada comes close, 
 > but simultanious Text_IOs will kill the application. Tasks and I/O are 
 > NEVER a no-brainer.

   There are several versions of the Verdix compiler targeted to
multi-processor systems which do this, and do it very well.  The first
was for the National chip-based Sequent machines.  And the same
run-time has been ported to several other systems.

   But this is, and always has been, an issue outside the scope of the
language.  If the operating environment supports multiple processes
doing I/O to the same devices at the same time, it is nice to have a
compiler which recognizes that and takes advantage.  But the overhead
to do that under "vanilla" Unix is harsh, and under MS-DOS it is darn
near impossible.

   But it has always surprised me that (especially on Unix) no vendors
have built their I/O packages around a "two process" model.  The main
program and all user defined tasks run in a single process, but you
have a package that mediates all I/O events and hands them to a second
process which does the waiting and event handling.  If done right,
most of the I/O can be done no wait from the point of view of the
second process, and only the task in the main program which made the
call does the waiting.

   While such a run-time may be overkill for most programs, the amount
of code that needs to be changed is small, and usually buried in one
or more implementation defined packages.  It shouldn't be hard for a
vendor to do a switchable implementation, and allow the user to switch
at link-time.  Or, if you are adventurous, it is about a three week
effort if you have access to the source code for the implementation
defined library units.  (Yes, I've done it.)  Of course, GNAT is going
for a full threads based run-time, but even in GNAT, this style of
run-time would better serve most users in some environments.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...