!standard  4.8(10.3/2)                               10-02-10    AC95-00185/01
!standard  9.2(6/3)
!standard  9.3(5)
!class confirmation 10-02-10
!status received no action 10-02-10
!status received 09-11-05
!subject New dependent task created during task finalization
!summary

!appendix

!topic New dependent task created during task finalization
!reference 9.2, 9.3
!from Adam Beneschan 09-11-05
!discussion

When a task completes, 9.3(5) says that the first step is to wait for the
completion of any tasks dependent on the master (i.e. the task body).  Then any
other finalization is performed.

What happens if the other finalization causes a new task to be created that
depends on the task body?

   task body T is

      task type T2 is
      end T2;

      task body T2 is
      begin
      end T2;

      type T2_Access is access T2;
      A : T2;

      type Fin_Type is new Ada.Finalization.Controlled with null record;

      overriding
      procedure Finalize (Obj : in out Fin_Type) is
      begin
         A := new T2;
      end Finalize;

      F : Fin_Type;

   begin
      null;
   end T;

As I read it, when F is finalized, a new task is created by an allocator, and
9.3(2) says that this new task depends on T's task body, since that is the
master that declares the access type.  This seems anomalous to me, since at the
point Finalize is called, T was supposed to have already finished waiting for
its dependent tasks to terminate, and if we get there then all its dependent
tasks have terminated, and now we go and create a new dependent task---when is T
supposed to wait for this new task to terminate?

I don't think 9.2(6/3) addresses this situation.  There may have been some
proposed wording in AI05-45 that would have addressed it, but I don't believe
this case is covered by the current RM05 wording.

I think that perhaps a new rule needs to be added, the one added by AI05-45,
that says that if a new task is created that depends on a master that has
already completed, the new task becomes terminated and is never
activated---something like that, maybe?

****************************************************************

From: Bob Duff
Date: Thursday, November 5, 2009  3:30 PM

> What happens if the other finalization causes a new task to be created
> that depends on the task body?

I thought there was an AI on that, and it said it's a bounded error to do that.
But I can't seem to find it right now.  I think GNAT raises an exception if you
do that.

****************************************************************

From: Edmond Schonberg
Date: Thursday, November 5, 2009  4:02 PM

No, there is no problem, and GNAT does not raise an exception.
However, the dependent task does not get activated. Not clear that this is the
proper semantics...

****************************************************************

From: Randy Brukardt
Date: Thursday, November 5, 2009  9:10 PM

Bob is right that there is an AI; Steve Baird found it. It is AI95-00280, and it
leads to 4.8(10.2-3/2), the latter paragraph answers the question:

  If the object to be created by an allocator contains any tasks, and the master
  of the type of the allocator is completed, and all of the dependent tasks of
  the master are terminated (see 9.3), then Program_Error is raised.

In the example, the allocator depends on the master of T's body, and the other
conditions are all true. So Program_Error is raised by the allocator. Thus the
situation postulated by Adam can't happen in this example.

I do wonder if there is some way to cause this problem that doesn't involve an
allocator. If that is true, then there is a hole somewhere (presumably, it ought
to be fixed the same way). What happens if the Finalize routine is:

      overriding
      procedure Finalize (Obj : in out Fin_Type) is
         TO : T2;
      begin
         null;
      end Finalize;

Humm, I guess the procedure has it's own master. That master will depend on one
that is already awaited (which is weird), but it itself will follow the normal
rules (and it hasn't been waited for yet). Not sure that there is any problem
here.

****************************************************************