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.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,fca4fc92ad494c1f
X-Google-Attributes: gid103376,public
From: Stephen Leake <Stephen.Leake@gsfc.nasa.gov>
Subject: Re: Tasking question (not the same as ^^^)
Date: 1997/10/10
Message-ID: <343E40D8.1901@gsfc.nasa.gov>#1/1
X-Deja-AN: 279225848
References: <61kipb$p28$1@reader1.reader.news.ozemail.net>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Reply-To: Stephen.Leake@gsfc.nasa.gov
Newsgroups: comp.lang.ada
Date: 1997-10-10T00:00:00+00:00
List-Id: <comp.lang.ada>


Paul Van Gorp wrote:
> 
> begin
> 
> ...
>         loop
>                 ch := Getch;
>                 user.input_entered(ch);
>         end loop
> ...
> end ...;
> 
> Now, It may be a rotten way to do it, but it works fine when there is > no
> facility for a simple keyboard interface, the tasks all seem to not > operate
> when input is being awaited from the keyboard.
> 
> It seems to work fine when I hardcode input ( user.input_entered(...) > ) in the
> main part of the program.

Getch is not a standard Ada function, so I don't know what it really
does. It appears to halt the entire process, including all tasks, while
waiting for input. This is typical of many Ada implementations; it
depends on the operating system, and how the Ada runtime maps tasks to
operating system processes or threads. There may be a compiler switch to
influence this mapping. 

Another possible solution is to use Text_IO.Get_Immediate; on some
systems, this does not block all tasks.

Always give info on your compiler and OS in help requests. It doesn't
cost you much, and you are much more likely to get a good answer!

> 
> Thanks in advance..

You're welcome.
> 
> Paul

-- 
- Stephe