Re: a tasking question for you

Re: a tasking question for you

[stt]

Although I agree it is not specific here, it would not
be meaningful for a rendezvous to continue after
the caller receives TASKING_ERROR and begins to process it.
A rendezvous by definition occupies the full attentions
of both tasks.  To be clear, it should probably say
that TASKING_ERROR is raised no sooner than the completion
of the rendezvous, and no later than the abnormal completion
of the aborted task.

As far as 9.10:8 -- Imagine a variable which is a large record
being updated by record assignment.  If a task is aborted
and becomes completed in the middle of the assignment,
then the value of the variable may be unmeaningful, with
the record only partially updated, and perhaps even a single
component only partially updated.  In this sense,
the value is formally "undefined," which means that it is erroneous
to use or rely on the value.  Similar wording appears
in 3.2.1:17/18, where it states that "The execution of
a program is erroneous if it attempts to evaluate a scalar
variable with an undefined value.  Similarly, the execution
of a program is erroneous if it attempts to apply a predefined
operator to a variable that has a scalar subcomponent with an
undefined value."

S. Tucker Taft
c/o Intermetrics, Inc.
Cambridge, MA  02138

Re: a tasking question for you

[Keith Shillington @prodigal]

The situation you describe with respect to 9.10(7) is impossible.
A cannot possibly resume execution be it via TASKING_ERROR or normal
circumstances until B completes the rendezvous.  The last sentence in 
9.10(6) warrants the completion of the rendezvous.  11.5(5) and 9.5(14)
warrant the order of execution.

9.10(8) [Bonus Answer] Refers, at least, to situations such as an exception
being raised in the process of the assignment; consider, for example, the
situation where a CONSTRAINT_ERROR is raised in evaluating the right hand
side of an expression.  The task becomes abnormal, and the value of the
variable is undefined.

Keith Allan Shillington      telesoft!keith@UCSD.ARPA
...!sdcsvax!telesoft!keith.UUCP  619/457-2700x388.ATT

a tasking question for you

[Doug Bryan]

Dear Ada Fans,

After a long summer break, we're back with our pain-in-the-rear 
questions.  We have a nasty one about the semantics (or lack thereof) 
of RM 9.10(7).  Consider the following:

     with Text_Io;
     procedure Main is
        type Text is access String;

	task A;
	task B is
	  entry E (T : Text);
	end B;

	T : Text := new String'("xxxx");

	task body A is
	begin
	  B.E (T);
	exception
	  when Tasking_Error =>  Text_Io.Put_Line (T.all & T.all);
	end A;

	task body B is
	begin
	  accept E (T : Text) do
	    T.all := "yyyy";
	  end E;
	end B;
     begin
	abort B;
     end Main;

Is it possible for this program to print:

	xxxxyyyy

The following scenario seems possible (assuming a single
CPU system simplifies life):

	1. the rendezvous begins
	2. task B becomes abnormal (but not completed)
	3. Tasking_Error is raised in task A
	4. task A handles the exception
	5. the left-hand operand of "&" is evaluated (yielding "xxxx")
	6. task B executes the assignment statement 
	7. the right-hand operand of "&" is evaluated (yielding "yyyy")
	8. the Put_Line takes place

The wording in 9.10(7) seems not to preclude an abnormal task engaged
in a rendezvous from continuing execution AFTER the caller has received
and/or handled Tasking_Error.  If this is possible, then the called task
can still be mucking with actual parameters, while the calling task has
continued its own execution.  

If this is possible, we'll never use Ada again!  'C' doesn't have this
problem!! :-)

Bonus Question:  What does 9.10(8) have to do with the price of eggs?
	We don't understand how this could happen.

doug and geoff
-------