* Re: Tasking question (not the same as ^^^)
1997-10-10 0:00 Tasking question (not the same as ^^^) Paul Van Gorp
@ 1997-10-10 0:00 ` Matthew Heaney
1997-10-10 0:00 ` Robert Dewar
1997-10-10 0:00 ` Stephen Leake
1997-10-30 0:00 ` Balmacara9
2 siblings, 1 reply; 6+ messages in thread
From: Matthew Heaney @ 1997-10-10 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Tasking question (not the same as ^^^)
1997-10-10 0:00 Tasking question (not the same as ^^^) Paul Van Gorp
1997-10-10 0:00 ` Matthew Heaney
@ 1997-10-10 0:00 ` Stephen Leake
1997-10-11 0:00 ` Paul Van Gorp
1997-10-30 0:00 ` Balmacara9
2 siblings, 1 reply; 6+ messages in thread
From: Stephen Leake @ 1997-10-10 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread