From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 13 Aug 93 16:15:20 GMT
From: cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!falis@ucbvax.Berkele
y.EDU  (Edward Falis)
Subject: Re: Language runtime requirements (was Re: DoD
Message-ID: <1993Aug13.121520.1158@sei.cmu.edu>
List-Id: <comp.lang.ada>

In regard to Dave Bashford's question: "So, what's the problem with
UNIX", I'll make the following observations / HO's:

Solaris, HP-RT, LynxOS are effectively UNIX or UNIX variants.  The difference
from traditional UNIX implementations ispport for threads or lightweight
processes.  This s a key issue for mapping Ada tasking over the operating
system schedulable entities.

For starts, UNIX process switching times are quite large, because such a
process has much more context associated with it (including a separate
address space) than an Ada task does.  In view of the complaints of
the user comunity about Ada context switch and rendezvous times bac 

when these design deision were made, it  did not seem sensible to add
this overhead to operatons that were already on the heavy side.  Given
that Ada tasks can potentially share address spaces, there are additional
overheads incurred to map shareable address spaces among multiple UNI|
processes.  Both of these problems are solved by threads, since they're
defined within the shared address space of the process corresponding to
the Ada mai subprogram, and threads have much less context associated
with them than processes.  

The upside of using threads or processes for Ada tasks is that the
tasks are scheduled by the OS, so that blocking operations allow
other parts of the application to proceed.  So in light of these
considerations, threads are almost ideal.

What we wound up having to do with the approach of mapping all Ada
tasks into a single process, was to provide ways of having blocking
operations inform the Ada scheduler to switch to another task.
Initially, this was done for standard I/O operations, and Kludges
were made available on some platforms to fork off a child process
for system calls and calls to other languages that might block.
Very ugly, and it still didn't address issues like priorities
across multiple applications.

Hope this gives a little perspective on where we were coming from.

- Ed Falis, Alsys