Tasking question (not the same as ^^^)

Tasking question (not the same as ^^^)

[Paul Van Gorp]

I am having this strange problem with tasking, here is the scenario...

task DO_STUFF is
	entry do_stuff1(...);
	entry do_stuff2(...);
end DO_STUFF;

task user is	-- interacts with DO_STUFF
	entry input_entered(c: Character);	-- the body for this interacts with DO_STUFF
end user;

-- 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.

Wondering if anyone might have a clue as to what the program might be...

Thanks in advance..

Paul

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

[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

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

[Stephen Leake]

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

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

[Robert Dewar]

Matthew said

<<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.>>

Nearly all ports of GNAT map Ada tasks to operating system threads, so 
although it may be a perennial problem in Ada systems of the past, and
perhaps of some others of the present, it is certainly NOT a problem 
with GNAT.

Robert Dewar
Ada Core Technologies

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

[Paul Van Gorp]

>
>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!
>
Oops, forgot to mention that, I'm running GNAT 3.07 under Windows95.

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

[Balmacara9]

>Subject: Tasking question (not the same as ^^^)
>From: paulvg@eelab.su.oz.au (Paul Van Gorp)
>Date: Fri, Oct 10, 1997 02:42 EDT
>Message-id: <61kipb$p28$1@reader1.reader.news.ozemail.net>
>
>I am having this strange problem with tasking, here is the scenario...
>
>task DO_STUFF is
>	entry do_stuff1(...);
>	entry do_stuff2(...);
>end DO_STUFF;
>
>task user is	-- interacts with DO_STUFF
>	entry input_entered(c: Character);	-- the body for this interacts
 with
>DO_STUFF
>end user;
>
>-- 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.
>
>Wondering if anyone might have a clue as to what the program might be...
>
>Thanks in advance..
>
>Paul
>
>
>
>
>
>
>
>
>
>

Your OS may be blocking your entire process when you call the Getch function or
 the Read function. I have dealt with serveral Unix compilers which did not use
 Posix/Native threads to implement tasking. Look in the appendix F of your
 compiler manual.