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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,21084fc6af5f3dfd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-02-10 04:35:38 PST Path: nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!agate!overload.lbl.gov!lll-winken.llnl.gov!noc.near.net!eisner!kilgallen From: kilgallen@eisner.decus.org (Larry Kilgallen, LJK Software) Newsgroups: comp.lang.ada Subject: Re: Unbuffered keyboard input on VAX ADA? Message-ID: <1995Feb10.073538.9088@eisner> Date: 10 Feb 95 07:35:38 -0500 References: <3gp9mm$kfi@covina.lightside.com> <1995Feb3.103003.9017@eisner> Organization: DECUServe Date: 1995-02-10T07:35:38-05:00 List-Id: In article , emery@goldfinger.mitre.org (David Emery) writes: > This example indicates why, in my opinion, such "thin bindings" are A > Bad Thing. I presume you refer to the fact that there are two status codes to be checked (actually the TASKING_* bindings cited by one user are not all that thin, being developed specifically for Ada tasking support). Regardless of possible rearrangement of the parameters, asynchronous IO will always require two status checks on VMS (or any other OS, so far as I can see), one for when the request is queued and one for when it is completed. If the request does not get queued, the event which indicates completion (AST for VMS) will never happen. Of course an exception could be raised in place of one of the failure returns if it was extremely unlikely, but that probability cannot be predicted by the designer of bindings. While the class problem which started this presumed there was a single keyboard, in a real situation there could be a score of keyboards, some potentially in use by other jobs on the computer system at the time when I/O is requested.