CVS difference for ai05s/ai05-0111-2.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0111-2.txt

--- ai05s/ai05-0111-2.txt	2010/06/13 03:24:46	1.1
+++ ai05s/ai05-0111-2.txt	2010/10/26 05:39:46	1.2
@@ -1311,3 +1311,163 @@
 
 ****************************************************************
 
+From: Bob Duff
+Sent: Sunday, June 13, 2010  8:35 PM
+
+> Note that the language already does something pretty similar with task
+> objects, where those are really handles on underlying tasks.
+
+Most (all?) implementations do that, but I don't think the language forces it.
+Does it?  I was under the impression that "task control blocks" could be
+allocated entirely within task objects, with no heap allocation.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 14, 2010  7:27 AM
+
+One thing I should have said is that I
+also wanted to preserve the level of
+indirection because I believe it is
+very helpful if someone wants to add back in some kind of automatic reclamation
+in the presence of various kinds of references (e.g., pool-to-pool, strong
+references, and weak references).  I realize I was requested to remove much of
+that, but I wanted to make it possible for implementations to provide additional
+functionality without having to completely revamp the basic model.
+
+Weak references, in particular, are extremely useful to support caching, and
+they really depend on a level of indirection.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, June 14, 2010  12:08 PM
+
+>  I was under the impression that
+> "task control blocks" could be allocated entirely within task objects,
+> with no heap allocation.
+
+In Ada95, you could have something like
+
+   declare
+     type R is record
+       F1 : Integer := 123;
+       F2 : Some_Task_Type;
+     end record;
+
+     R_Var : R;
+
+     function F return R is
+     begin
+         return R_Var;
+     end F;
+
+     procedure P (X : R ) is
+     begin
+        R_Var.F1 := 456;
+        pragma Assert (X.F1 = 123);
+     end P;
+   begin
+     P (F);
+   end;
+
+Assuming that it is not ok to make a copy of a TCB, this is difficult to
+implement correctly if a TCB is stored within the task object itself.
+
+For later versions of the language, I think you are right.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, June 14, 2010  1:19 PM
+
+Maybe I'm missing something, but that doesn't seem right to me.
+R is a return-by-ref type (in Ada 95!), so F returns a view of R_Var, and X is a
+view of that same thing, so after "R_Var.F1 := 456;", "X.F1" must be 456.  Not
+copies needed or allowed.
+
+> For later versions of the language, I think you are right.
+
+Right, for later versions, the above is illegal.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, June 14, 2010  1:42 PM
+
+You're right. I was confused.
+Sorry about the noise.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 14, 2010  1:22 PM
+
+It is (much!) easier to implement the
+unchecked-deallocation rules if
+the TCBs are not embedded in the
+task object.  Remember that tasks
+keep executing after unchecked
+deallocation.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Sunday, June 20, 2010  5:34 PM
+
+To combine Randy's notion of Unchecked_deallocation of subpools with the
+ref-counting model and make dangling references commission errors again, try the
+following semantics:
+
+Unchecked_Deallocation (give it a different name, such as Unchecked_Free) of
+subpools is the only way to deallocate them. Masters do not matter for
+deallocation semantics. However, actual deallocation happens only if the
+reference count of the subpool is zero. In any case, however, the
+allow-references links emanating from the subpool are deleted and the subpool
+cannot be used for allocation any more. It can still be used as target for
+allow_references, though. (The latter to correctly deal with assignment to
+components of surviving objects in the subpool.)
+
+Now it is up to the deallocator/free-er to ensure that allow_references are set
+sufficiently to avoid dangling references. It is a commission error (i.e.,
+erroneous) to free a subpool while the allow-references are incorrectly set.
+
+Maybe a disallow_references interface is needed to withdraw links individually.
+
+(The model is probably not completely safe because manipulations of objects  in
+an Unchecked_Free subpool can mess things up, but it is miles better than  the
+dangling references due to omission errors.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, June 22, 2010 11:12 AM
+
+This looks like an interesting compromise.
+
+I would be against providing "Disallow_Reference"
+as that dramatically increases complexity of implementation of circularity
+handling. It also breaks several assumptions of the more sophisticated
+approaches to safety which I still hope implementations can "layer on" at a
+later time if they so choose.
+
+I see "Allow_Reference" as a kind of "commit"
+which cannot be withdrawn.  All you can do is get rid of the handle to the
+"from" subpool (by doing an unchecked-delete-subpool) which will effectively
+eliminate the reference to the "to" subpool once the "from" subpool is
+unreachable.
+
+Since this proposal does not allow immediate deletions of the subpool, but
+rather deletes the handle on the subpool, it might mean that the routine's name
+should reflect that, such as "unchecked_delete_subpool_handle."  This is saying
+there are no further pointers to the subpool from local variables.  There might
+still be pointers to the subpool from other subpools, and only when those
+subpools are no longer reachable is the underlying subpool reclaimed.
+
+It might be considered an error to exit the scope of a subpool handle without
+explicitly calling a delete on the handle, as it would create a storage leak.
+That error could presumably be eliminated in implementations that add
+reachability checks, thereby allowing them the confidence that there are no
+dangling references into the subpool.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent