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.6 required=5.0 tests=BAYES_05,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!harvax.UUCP!harold From: harold@harvax.UUCP (Harold Rabbie) Newsgroups: comp.lang.ada Subject: Interactive I/O in Ada Message-ID: <9001232125.AA09245@monolith.> Date: 23 Jan 90 21:25:30 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: Bill Wolfe writes: >> In the current issue of ACM SIGAda Ada Letters, Doug Bryan provides >> a simple answer to a commonly asked question: How does one do keyboard >> input in Ada while having other tasks do some work in the background >> in between keystrokes? Since Text_IO generally is >> not implemented so as to permit this to be done trivially ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ My question is: WHY NOT? The reason TEXT_IO isn't pre-emptible on most systems is that the scheduler in the underlying OS isn't aware of the Ada tasking scheduler. It blocks on the call to read() or whatever, never allowing the Ada scheduler to regain control. This is just a BAD IMPLEMENTATION. There's no reason why TEXT_IO shouldn't check before issuing a potentially blocking system call, and then use an asynchronous type of request. Better yet, on embedded systems, you can use an operating system that only has a single level of scheduling. If an Ada task makes a blocking call, like TEXT_IO, then the scheduler can find another Ada task to run. Moral of the story: if real-time I/O is important to you, then use a real-time Ada OS. Accept no substitute. --------------------------+-------------------------------------------- Harold Rabbie, Ready Systems "when REAL_TIME => accept READY_SYSTEMS;" UUNET: {sun!pyramid,hplabs}!harvax!harold ARPA: rabbieh@ajpo.sei.cmu.edu --------------------------+--------------------------------------------