CVS difference for ais/ai-00345.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-00345.txt

--- ais/ai-00345.txt	2004/01/27 03:31:04	1.8
+++ ais/ai-00345.txt	2004/02/04 00:51:13	1.9
@@ -2966,3 +2966,76 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Monday, January 26, 2004 11:43 PM
+
+> ...
+> Requeue is a mess, but the primary problem is hidden generic parameters (for
+> sharing), which might have to disappear or change or appear. "Disappear" is
+> easy enough, but I've never come up with a way to do the other cases. You
+> can't copy the parameters, because we use value-result passing for small
+> scalar types.
+
+When using a parameter block, we simply include the address of a temp
+as a component of the parameter block to deal with by-copy [IN] OUT
+parameters.
+
+> ... And you certainly can't write over memory that you don't own!
+> (We simply refuse to compile problem requeues - not a lot of complaints to
+> date on that.)
+
+I presume most other vendors have solved this somehow.
+I don't think we should bless a restricted requeue (despite
+Robert Eachus' comment).
+
+> (This is one the places were a number of reasonable appearing choices work
+> together to make something impossible to implement. C'est la vie.)
+
+Yes, that happens...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 27, 2004 12:26 AM
+
+Tucker said, replying to me:
+> When using a parameter block, we simply include the address of a temp
+> as a component of the parameter block to deal with by-copy [IN] OUT
+> parameters.
+
+"Simply"? Sure, you can selectively turn off value-result passing for all
+entry calls. That has always seemed too much like admitting defeat to me.
+(You can punt on 2nd down, too, but that doesn't make it a good idea...)
+
+> > ... And you certainly can't write over memory that you don't own!
+> > (We simply refuse to compile problem requeues - not a lot of complaints to
+> > date on that.)
+>
+> I presume most other vendors have solved this somehow.
+> I don't think we should bless a restricted requeue (despite
+> Robert Eachus' comment).
+
+They don't have shared generics. At least ones with protected and task types
+declared in them. (The problem only can occur when doing an external requeue
+to an object of a task or protected type declared in a generic unit from
+some object whose type is not in that unit. This isn't common.)
+
+But I certainly don't want to "bless" such a restriction. I just was
+commenting that I didn't think that the "parameter block" really made much
+difference in the difficulty of requeue either way. (The generic parameter
+problem would occur either way.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, January 27, 2004  1:09 AM
+
+It helps a bit I think because the parameter block holds the
+"primary" parameters to the entry, while the auxiliary
+parameters such as the static link, generic instance
+descriptors, entry index, etc., could be passed separately.
+The "primary" parameters don't change upon requeue, whereas
+the auxiliary parameters typically do.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent