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!mit-eddie!ll-xn!ames!ucbcad!ucbvax!GWUVM.BITNET!MFELDMAN From: MFELDMAN@GWUVM.BITNET (Mike Feldman) Newsgroups: comp.lang.ada Subject: Re: user-defined "="; synchronous vs. asynchronous I/O Message-ID: <8801081711.AA05859@ajpo.sei.cmu.edu> Date: 8 Jan 88 16:34:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: As the one who made the request for discussion on the issue of user- defined "=" and ":=", I just want to thank Robert Firth publicly for a _very_ enlightening response. At the risk of sounding a bit preachy, I'd like to say that this kind of issues discussion - like the ones on inheritance and terminate-and-stay-resident tasks, is what I joined the list for, and I hope we can continue on this plane. What bores me silly is frequent re-hashing of the "my language is better than yours" variety. Now that there are nearly 150 validated compilers out there, of reasonably good quality for the most part, I hope the powers that be won't object too much if the discussion leads sometimes to comparative discussion of implementations, with the understanding that pure hype or unsubstantiated bad-mouthing is foul play. I can't think of a common host/target pair that doesn't have at least 2 roughly comparable implementations available, and this makes possible the competition between implementers that was (I think) always contemplated by the Ada forefathers. For example: recently there have been some postings regarding interrupt-driven console I/O on PC's, for example. I have the fairly clear impression that TEXT_IO wasn't really intended to be used in a tasking environment - some early implementations like the interim (subset) TeleSoft compiler in fact implemented TEXT_IO asynchronously, so that if one task executed PUT("ABC") and the other PUT("DEF") the actual I/O was done character by character, so that one saw ADBECF on the screen. Here there was clearly a context-switch every time an I/O call was being done. What we have now, in every recent implementation I've used, is that the TEXT_IO procedures really have the abstraction of procedures rather than entry calls, so that (1) a calling program waits until the call is completed before proceeding and (2) no (logical) interruption and context switch is done within the I/O routines themselves. (Of course there may be physical interruptions and reschedulings if the target OS is a time- sharing system like Unix or VMS). Thus, assuming that PUT("ABC") was done first, one would see ABCDEF as the procedure abstraction would suggest. Now the questions for the experienced users in net-land (and/or authorities like Robert Firth): (1) Is my impression about procedure abstractions approximately correct? That is, does prevailing wisdom and AdaBoard policy dictate that TEXT_IO looks synchronous to the calling program? (2) Assuming the answer to (1) is essentially "yes", what are the various implementers doing to provide useful _asynchronous_ I/O, in particular on the input side, so that the difficulty with ENUMERATION_IO posted a couple of days ago can be coded around? Which vendors are providing useful interrupt-driven console input in their libraries? (3) Is anything happening at a more implementation-independent level (in the CAIS community, perhaps) to provide this kind of I/O service in a more standard way? I'm not using the term "portable" because the transaction style on, say, a VM mainframe will always be fundamentally different than that on a PC. On the other hand, it'd be nice if one could port code between different PC implementations without excessive (ideally without any) re-coding. Comments? Lessons learned? You can respond to me directly or to the net. Mike Feldman, Dept. of EECS, George Washington University MFELDMAN@GWUVM.BITNET