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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!bloom-beacon!martillo From: martillo@bloom-beacon.UUCP Newsgroups: comp.lang.ada Subject: Re: Microsoft OS/2 -- Ideal for Ada Message-ID: <940@bloom-beacon.MIT.EDU> Date: Tue, 16-Jun-87 18:24:02 EDT Article-I.D.: bloom-be.940 Posted: Tue Jun 16 18:24:02 1987 Date-Received: Thu, 18-Jun-87 03:17:19 EDT References: <8706130340.AA00283@rand-unix.arpa> <928@bloom-beacon.MIT.EDU> <1624@aw.sei.cmu.edu> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: martillo@athena.mit.edu (Yakim Martillo) Distribution: world Organization: MIT Project Athena List-Id: In article <1624@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP (PUT YOUR NAME HERE) writes: >In article <928@bloom-beacon.MIT.EDU> martillo@athena.mit.edu (Yakim Martillo) writes: >>The correct question is whether the language implementer should >>be mapping an Ada task into a Unix fork... >>Providing language level tasking by simulating non-existent tasking >>instructions should be no more than a couple of days work for the >>compiler writer. The implied criticism of Unix in this article is >>gratuitous and implies a lack of understanding. >I agree that it is inappropriate to map Ada tasks into Unix processes. >For one thing, the overhead is insupportable. >Unfortunately, the alternative doesn't work either. Two serious >problems >(a) Unix does not provide asynchronous IO to a process. If one Ada task > does a read() from the terminal, the whole program blocks. And you > thought polling died out in the '60s? Actually, Berkeley Unix does provide asynchronous I/O. If you use substandard AT&T versions of Unix, you get what you deserve. >(b) A large number of Unix system calls are not reentrant. If one Ada > task is suspended in a malloc(), chaos can ensue. This is a library problem not a language problem. >These problems (and others) cannot be fixed by the compiler writer. >All he can do is curse Unix (and rightly so, in my opinion) for a grossly >simplistic view of what "computation" is. Since I myself have written multitasking packages for Unix which would more than satisfy the needs of ada programming, I find this claim rather dubious. As for simplistic view of what computation is, I would be curious how it is simplistic, the Unix designers set out to define a true multi-user, multi-tasking, time-shared system with logical I/O and a limited virtual machine capability. As far as I know Unix is one of the few systems which achieve this. None of the IBM systems qualify, nor does VMS nor does Multics nor does Multics -- at least from what I can tell from groveling through the source. I would say that Unix achieves this precisely because of the powerful simplicity of the operating system because the Unix developers made the correct choice of fundamental operating system entites, the file and the process and then constructed a rather sophisticated system on top of these elements. Unix loses in providing real-time capability and dynamic linking but the developers limited their goals (a very good thing to do) and did not intend to provide such capability although I do not think they would be particularly hard to add if the developer has a proper understanding of the Unix model of computation.