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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!DCA-EMS.ARPA!jmoody From: jmoody@DCA-EMS.ARPA (Jim Moody, DCA C342) Newsgroups: comp.lang.ada Subject: synchronous v. asynchronous I/O Message-ID: <8801112034.AA19297@ajpo.sei.cmu.edu> Date: 11 Jan 88 19:13:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: Mike Feldman (MFELDMAN@GWUVM.bitnet) writes "I have the fairly clear impression that TEXT_IO wasn't really intended to be used inin a tasking environment." I don't see why TEXT_IO is any different from any other I/O package in a tasking environment. Any tasking rpogram which accesses a file from two (or more) tasks has to be careful. Section 9.11 applies. Implemetations which block all tasks when one does I/O to standard_input or standard_output are "protecting" programmers from the ill-effects of writing erroneous programs, because a whole bunch of people wrote erroneous programs (the example Mike gives is one task doing PUT("ABC") and another doing PUT("DEF") with the screen result ADBECF) and complained when the implemenation did the unexpected. Section 9.11 says that if one task updates a shared variable, another should not without explicitly synchron- izing with the first. standard_output is a shared variable. It seems clear to me that part of the pijt of allowing tasking in a single processor environment is to continue computing while the guy at the terminal is scratching his head. This mandates context switching at I/O points. I hope that there is no AdaBoard policy which opposes this view. Jim.