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,98caa5b030058ecf
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-10-30 19:06:14 PST
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!swiss.ans.net!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody
From: dewar@cs.nyu.edu (Robert Dewar)
Newsgroups: comp.lang.ada
Subject: Re: Say it isn't so! (Formerly: Ada replacements for DOS I/O)
Date: 30 Oct 1994 10:31:28 -0500
Organization: Courant Institute of Mathematical Sciences
Message-ID: <390e8g$f0m@gnat.cs.nyu.edu>
References: <2EB14997@SMTPGATE2.STRATCOM.AF.MIL>
NNTP-Posting-Host: gnat.cs.nyu.edu
Date: 1994-10-30T10:31:28-05:00
List-Id: <comp.lang.ada>

THe important thing to realize is that the Ada language has nothing to
say about whether I/O operations allow other tasks to proceed, nor could
it, since this is a highly operating systems dependent feature. In some
operating systems (e.g. DOS) it is close to impossible to do overlapping.
In a Unix without threads, it is also difficult. 

In a Unix with threads, you cannot assume that Ada tasks are mapped to
different threads. If they are, then almost certainly I/O is overlapped.

THe bottom line here is that you need to ask specific questions about
your implementation before making assumptions that are unwarranted. If
you require overlap, then make sure that your implementation supports it.

Calling it appalling or a bug, or whatever is really besides the point. THere
are many implementation dependent features in Ada (or in C or Fortran for
that matter), and one of the jobs of any programmer in any language is to
make sure that the compiler you are using supports the features that you
required.

Note that even in DOS, there are *some* cases where overlap can be achieved.
FOr example, it is definitely possible and desirable (though not required!)
to allow overlap of tasks with keyboard I/O, but disk I/O is pretty much
a lost cause.

Going back to the threads issue, it is very important for you to know
whether you need your Ada tasks mapped to threads, and if so, to insist
on this mapping. Typically mapping Ada tasks to threads introduces a lot
of extra overhead (light weight threads in most Unices aren't!) so a vendor
may assume that high performance on tasking is more important than this
mapping, and that decision may be right, it all depends on expectations
and planned usage.

In GNAT, we base our tasking implementation on posix threads. On a system,
like SunOS, which has no threads, we simulate the threads. This means that
we expect to take advantage of multiple threads if the operating system
provides them, and the implementation of GNAT tasking on the SGI does map
to separate threads.