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,1c3d4536a687b7b0
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2000-08-31 20:21:43 PST
Path: 
 supernews.google.com!sn-xit-02!supernews.com!ihug.co.nz!nntp.flash.net!mercury.cts.com!thoth.cts.com!not-for-mail
From: Wayne Lydecker <wayne@mtws.visicom.com>
Newsgroups: comp.lang.ada
Subject: Re: Ada 95 tasking problems with Ada 83 code
Date: Thu, 31 Aug 2000 20:21:50 -0700
Organization: CTSnet Internet Services
Message-ID: <39AF20CE.FDBDFFFE@mtws.visicom.com>
References: <39ADAE51.30550667@mtws.visicom.com>
 <39ADD3A3.381DEF17@ix.netcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: thoth.cts.com 967778490 78253 63.207.143.75 (1 Sep 2000 03:21:30 GMT)
X-Complaints-To: abuse@cts.com
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD NSCPCD47  (Win98; U)
X-Accept-Language: en
Xref: supernews.google.com comp.lang.ada:456
Date: 2000-08-31T20:21:50-07:00
List-Id: <comp.lang.ada>

Richard Riehle wrote:
> 
> Wayne Lydecker wrote:
> 
> > I am porting a huge program from Ada 83 on HP-UX to GNAT Ada 95 on a PC
> > running Linux.  Creating the executable was not a big problem, but I
> > can't get it to run very far.  It appears that when a procedure rendezvous'
> > with a task, the task won't run.  The task has a simple accept statement,
> > and it appears to accept the rendezvous because the calling routine
> > continues to process.  Text_IO calls before and after the accept statement
> > in the task fail to appear on the screen though.  If I put a "do ... end"
> > on the accept statement then the caller no longer continues (i.e.
> > suspended).
> >
> > Is this a known problem?  Is there a solution other then removing all
> > tasks in our program (over 100).
> >
> 
> You mention the calls to Text_IO.  This is a potential source of trouble in
> tasking, especially
> if you have any kind of Get or Get_Line statements.   Recommend looking at
> Get_Immediate,
> and Look_Ahead as possible alternatives to other Get statements.  The standard
> Get statement
> blocks waiting for input but Get_Immediate can get whatever is in the buffer
> without waiting
> for a CR/LF.
><snip>
> Richard Riehle

That's it!  Turns out that the test program that starts the main
program creates a task that displays a menu and then uses a call to
text_io.get_line.  Evidently, the get_line in a task blocks the main
program.

I tried text_io.look_ahead, but end_of_line was always False.  Do
I have to check each character for <CR>?  Text_IO.Get_Immediate
works fine for single characters, but again I would have to search
for <CR>.

Would it work OK to reverse what is going on here and create a new task
to launch the main program and keep the test driver as a procedure?
Would the text_io.get_line still block the main program?

Thanks again Richard, I was about to perform a major re-write.  I
am almost complete with my task ;-)

-- Wayne.