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=-0.0 required=3.0 tests=BAYES_20 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 2 Aug 91 18:17:29 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!cs.u mn.edu!sctc.com!stachour@ucbvax.Berkeley.EDU (Paul Stachour) Subject: Re: Ada and Unix--Blocked Tasks Message-ID: <1991Aug2.181729.28061@sctc.com> List-Id: The methods indicated here seem kind-of wierd to me. After all, an Ada task is SUPPOSED to be an independent thread-of-control. And when I do something in Ada, I expect the run-time to arange to leave my other tasks alone, and only block the one needing the service. Now I understand that IF I import some non-Ada, specialized-system stuff into my Ada task, when I call it, it might have loads to do, and block till done. But that's what tasks are for! Doing the system-specific, unix-style signals seems to me to be at odds with doing things in Ada with tasks, yes? But then my first two experiences with Ada were with the Honeywell GCOS6 and GCOS8 systems. In the first, commands were normally done as tasks (as in Unix), and the Ada compiler and run-time adopted to OS mechanism to give the natural Ada parallelism by spawning an OS task whenever Ada would spawn an Ada task. And in GOCS8, they used the batch/tss subtask mechanism to accomplish the same results. Thus Ada tasks acted as they should, like real tasks. Which leads us to the basic question: If the Ada system you are using can't do tasking "correctly" (i.e., in a non-blocking way) in its implementation, what is in error? Is it the OS (unix in this case)? Your Ada compiler vendor (Don't know who)? Your Ada run-time vendor? Or something else? Yours, ...Paul -- Paul Stachour SCTC, 1210 W. County Rd E, Suite 100 stachour@sctc.com Arden Hills, MN 55112-3739 [1]-(612) 482-7467