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 00:20:52 GMT From: cis.ohio-state.edu!math.ohio-state.edu!cs.utexas.edu!utah-morgan!hellgate .utah.edu!peruvian.cs.utah.edu!matwood@ucbvax.Berkeley.EDU (Mark Atwood) Subject: Re: Language runtime requirements (was Re: DoD Message-ID: <1993Aug12.182052.16792@hellgate.utah.edu> List-Id: In article <1993Aug12.224346.20541@scf.loral.com> bashford@srs.loral.com (Dave Bashford) writes: >In article ... falis@ajpo.sei.cmu.edu (Edward Falis) writes: >>... For OS' that don't >>provide lightweight processes, we generally map all tasks into a single >>process. ... > >So, why the problem with Unix ? I've heard excuses like "it would be too >inefficient." But Unix/C has been using multi-tasking well for years. >Besides, I'd take inefficient over useless any day. I've used Alsys Ada on HPUX at work, and used a preemptive cthreads on BSD at school for an OS class. The problem I see with mapping Ada tasks on UNIX processes is that UNIX processes are too independent. Once a process starts, it doesn't share memory and doesn't have any sync points with the parent that forked it until it exits. Admittadly it COULD be done using pipes and/or OS supplied shared memory or sync resources, but it would be a major design pain. Threads are a model of multiple tasks that are closely related. Processes are a model of multiple virtual processors. You could use one of the several Ada socket or distributed processing packages to build a multi-process Ada system, but I don't think tasks map to processes very well -- Mark Atwood | My school and employer have too many problems matwood@peruvian.cs.utah.edu | without being blamed for mine.