Re: Tasking issues

[anon@anon.org (anon)]

First the 'ABORT' statement is a legal statement. Yes, there are better 
ways to terminate the task, but that would mean a complete overhaul of 
shaunpatterson's program, which could confuse shaunpatterson.

Also any statement that is valid in the language is valid in the code. And 
the people who say 'ABORT' statement is bad are just like the guys who 
said that "GOTO" in other languages or Ada's 'LOOP' statement is bad. 
Since "GOTO' or 'LOOP' statements are a high-level language version of 
the 'JMP' assembly instruction.  That concept that is just stupid, it 
comes from people who have no idea of how to program.  

Try and write code without jumping, which means you could never use 
the 'case', 'delay', 'do', 'else', 'elsif', 'exception', 'exit', 'for, 'goto', 'if', 
'loop', 'raise', 'select', 'terminate', 'then', 'until', 'when', while' 
statements. For jumping you could only use a subroutine call and 'return'
statement with no conditional statements or routines allowed.  

Now, shaunpatterson just wanted some understanding of the difference 
between C (fork) and ADA (task). For a deeper understanding he should 
always go to the library or buy an Ada programming book. Or do a 
google search of Ada tasking example programs. Then type in the 
examples and compile and run them.


As for "Get_Line immediately", thats an error, The Ada code can not 
force the operating system or keyboard routine to abort. Try reading 
RM 7.6.1 (23).

23   (20) Abort is deferred during certain operations related to controlled
     types, as explained in 9.8.  Those rules prevent an abort from causing a
     controlled object to be left in an ill-defined state.

Since the keyboard routine in the operating system is one of the 
following define in RM 9.8

    6  a protected action;
   11  an assignment operation to an object with a controlled part.

or the 'Get_Line' procedure has connect to a secondary task { aka 
operating system's keyboard routine } and the execution is define in 
RM 9.8 as

   16  the point where the execution initiates the activation of another
       task;
or
   17  the end of the activation of a task;

where the another task { aka operating system's keyboard routine }.

But shaunpatterson does not want to read a book, so my explaination 
was good enough!

Also where is your example of how the code should be written without a 
complete overhaul of shaunpatterson's program. Only simple additions or ]
changes with some comment for him.

In <se8lag9odx40$.1ko5kq7eszy2u.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>On Sun, 12 Aug 2007 09:00:27 GMT, anon wrote:
>
>>    -- abort tasks.  But because get_name may be in the process of 
>>    -- obtaining data from standard_input. it may require a CR/LF 
>>    -- to be entered to fully abort the 'get_name' task.
>
>No, it should abort Get_Line immediately. The operations deferring abort
>are listed in 9.8(5).
>
>>  abort get_name ;
>
>Aborting tasks is a bad idea, almost always. If you have some shared
>objects which states might be changed outside an abort-deferred operation,
>then aborting will corrupt them. It is not always possible to do everything
>from a protected action (which is abort-deferred).
>
>Though asynchronous transfer of control is very much like abort, one can
>limit the scope of what gets aborted.
>
>-- 
>Regards,
>Dmitry A. Kazakov
>http://www.dmitry-kazakov.de