Re: Say it isn't so! (Formerly: Ada replacements for DOS I/O)

[rzy@dasc.nl (Rudy Zijlstra)]

"Bennett, Chip (KTR) ~U" <BennettC@J64.STRATCOM.AF.MIL> writes:

>Chris Warwick <cwarwick@FOX.NSTN.NS.CA> 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?

The problem you have i running two shedulers above each other. The OS 
schedeuler and the Ada internal scheduler. The OS scheduler knows
<nothing> about the fact that you are multithreaded (or however you want
to call it) and when the Ada (multi)task performs a (blocking) I/O, the
OS scheduler correctly blocks it. Keep in mind it knows (righly and
correctly) nothing about the Ada scheduler.... In other words, unless
you are running Ada 'native' on the target hardware, i.e. without
supporting OS, don't use tasking in Ada unless you are prepared to
accept penalties like these.

Rudy Zijlstra

#include <stddisclaimer.h>       This might not be the view of my employer.