Re: Tasking question (not the same as ^^^)

[mheaney@ni.net (Matthew Heaney)]

In article <61kipb$p28$1@reader1.reader.news.ozemail.net>,
paulvg@eelab.su.oz.au (Paul Van Gorp) wrote:


>-- and the mail program has this loop...
>
>begin 
>
>...
>        loop
>                ch := Getch;    -- doesn't have to be Getch, could just be
a read
>                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.

Is Getch a call that blocks the process?  Remember that when you leave the
world of Ada and make an OS call, that call can block the entire process,
and not allow the run-time Ada task scheduler to run, thus preventing any
tasks from running.  This is a perennial problem in Ada, usually when
you're running on top of an OS (read: UNIX) instead of bare board.

Sometimes the library call is written so that it's Ada-aware, and only
blocks the calling task, not the entire process.  For example, under VMS,
there's a library routine Tasking_QIOW, that, unlike its counterpart QIOW,
blocks only the task.

A solution is to invert the calling order - be a callee instead of a
caller.  That may mean making the I/O asynchronous.  For example, under
VMS,  you can issue a QIO with an AST entry that maps to a task entry
(protected object entry(?) or procedure(?) in Ada 95), so that when the I/O
completes, it calls you back, sort of like

-- issue I/O request that completes asynchronously
Get_Char (Ch'Address, 1, E'AST_Entry); 

accept E;

User.Input_Entered (Ch);

(Note: this is an Ada 83 style solution.)  Get_Char completes almost
immediately.  The reader task then waits for the interupt to occur.  While
it's waiting, other tasks in the system can run OK, because the process
isn't blocked.

You might be able to use Ada.Text_IO.Get_Immediate in Ada 95.  Then you
could basically poll the user in a loop, and if there's no input, just go
to sleep for a little bit.

You might even be able to get some mileage out of asynchronous transfer of
control.  Something like

protected Input_Manager is
   entry Get_Char (Ch : out Character);
   entry Interrupt_Handler (Ch : in Character);  -- I'm way out on a limb here
private
   entry Waiting;
   Input : Character;
   Character_Available : Boolean := False;
end;

protected Input_Manager is

   entry Get_Char (Ch : out Character) when not Character_Available is
   begin
      <issue system call to get a char, and to call Interrupt_Handler 
       when it's ready (illegal if system call is "potentially blocking"?)>

      requeue Waiting;
   end;

   entry Interrupt_Handler (Ch : in Character) when True is
   begin
      Input := Ch; 
      Character_Available := True;
   end;

   entry Waiting (Ch : out Character) when Character_Available is
   begin
      Ch := Input;
      Character_Available := False;
   end;

end;

task User is
begin
   ...
   loop
      select
         Input_Manager.Get_Char (Ch);
     then abort
         <do some work>
     end select;
   end loop;
...

This is a paper example.  As I haven't played around with this feature of
Ada 95 yet, there may be some problems with the example.  (As a matter of
fact I just happened to read that section of Norm's book this afternoon -
that fine tome is over 1000 pages, and it has taken me several months to
get to that point!)

Just make sure you're not making an OS call that blocks the process.  (Find
out if the system call Getch is Ada-aware.)

Hope that helps.

Matt

P.S. Bertrand wins the page-count contest though.  OOSC-2 is over 1200 pages!

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271