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 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,98caa5b030058ecf X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-31 06:52:24 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!paladin.american.edu!auvm!PSAVAX.PWFL.COM!CONDIC Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: comp.lang.ada Message-ID: <9410311448.AA27239@ajpo.sei.cmu.edu> Date: Mon, 31 Oct 1994 09:45:10 EST Sender: Ada programming language From: CONDIC@PSAVAX.PWFL.COM Subject: Re: Say it isn't so! (Formerly: Ada replacements for DOS I/O) Comments: To: INFO-ADA@ajpo.sei.cmu.edu Date: 1994-10-31T09:45:10-05:00 List-Id: From: Marin David Condic, 407.796.8997, M/S 731-93 Subject: Re: Say it isn't so! (Formerly: Ada replacements for DOS I/O) Original_To: PROFS%"SMTP@PWAGPDB" Original_cc: CONDIC >"Bennett, Chip (KTR) ~U" wrote: > >Chris Warwick wrote: > >> We just got burned on a project using Alsys Ada. Seems we had assumed that >> a multi-tasking Ada program would perform I/O is parallel with other >> processing. The system service call actucally halts all processing in the >> program until the system service is complete... > >> I don't mean to burn Alsys, since the bug(?) also exists in the Verdix >> compiler we are using. The difference is the Verdix is for Unix so we just >> sidestepped the problem by not using Ada tasks... > >We use SunAda (aka Verdix) with Motif. Does this mean that if an >application is drawing to the screen and number crunching at the same time >in a separate Ada task, that the "background" task is going to be suspended >for the same I/O interrupts that the "foreground" task is being suspended? > >Does everyone else consider this acceptable, or am I the only one that is >appalled? In my experience with DEC Ada for VAX/VMS, the same problem occurs. If a task performs an I/O operation, the runtime system does not consider the task blocked and thus has no reason to start running other tasks. I believe that we fixed this problem by juggling task priorities so that I/O tasks were at the bottom of the list, but I don't recall if the preemptive scheduling was able to interrupt the pending QIO. The only way to successfully fix this would have been to dip into very serious system calls within the context of the task to shoot the QIO in the head in the event that there was nothing pending. This may have been what we did, but it's been such a long time now and my two or three remaining brain cells have a hard time executing a successful "rendezvous" I don't know as I'd call this a "bug" because Ada never specified a scheduling algorithm, nor was I/O ever explicitly considered as some sort of tasking structure which would require the task to be blocked. (A call to "TEXT_IO.GET (ITEM => X);" was never specified to behave as the execution of "wait 1.0;" or "accept THIS_ENTRY;) Hence an implementation could legally consider the task to be running - not blocked - and do nothing to preempt it. I share your frustration in that it would be *extremely* handy for a task to be considered blocked or ready whenever the underlying operating system would consider a process blocked or ready. However, I can understand the difficulty of actually getting this to work. It isn't always easy to design an Ada runtime kernal and have it match up nicely with an underlying operating system that wasn't designed to deliberately support Ada. Pax, Marin Marin David Condic, Senior Computer Engineer ATT: 407.796.8997 M/S 731-93 Technet: 796.8997 Pratt & Whitney, GESP Internet: CONDICMA@PWFL.COM P.O. Box 109600 Internet: MDCONDIC@AOL.COM West Palm Beach, FL 33410-9600 =============================================================================== "I like to dive around in my money like a porpoise and burrow through it like a gopher and toss it up and let it hit me on the head." -- Scrooge McDuck ===============================================================================