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,MSGID_SHORT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 6 Aug 91 18:48:53 GMT
From: mips!murphy@decwrl.dec.com  (Mike Murphy)
Subject: Re: Ada and Unix--Blocked Tasks
Message-ID: <6629@spim.mips.COM>
List-Id: <comp.lang.ada>

In article <1991Aug6.040550.785@beaver.cs.washington.edu> mfeldman@june.cs.wash
ington.edu (Mike Feldman) writes:
>What Paul might be getting at is the notion that an Ada compiler could
>(should) map each Ada task onto an OS-level process. I see no reason in
>principle why this could not be done; indeed, I think there may be vendors
>who are doing it in Unix (can anyone confirm this?). I believe I heard
>that one of the MVS (IBM mainframe) Ada systems can map Ada tasks to MVS
>tasks (can anyone confirm?). In practice, I imagine that vendors are
>keeping an ada program - tasks and all - in one OS-level process for
>efficiency, reasoning that mapping tasks onto processes is overkill.

Sequent, Encore, and Alliant have Ada runtimes (based on the Verdix 
compiler) that can map tasking into multiple processes on Unix; but in 
each case the Unix is an extended Unix that provides some support for 
doing so.  Also, it is interesting to note that these systems do not 
simply spawn one process per task but instead spawn N processes, and
then switch T tasks between those processes, where T can be > N.
Intermetrics MVS compiler can map Ada tasks to MVS tasks.

Another problem to deal with that has not been mentioned, is that
LRM 9.8(4) suggests that you may have to poll the other processes
in order to determine what tasks to run.

--mike murphy