!standard 9.5.2(3) 02-06-13 AC95-00041/01 !standard 9.5.2(8) !class amendment 02-06-13 !status received no action 02-06-13 !subject Incomplete types and dispatching. !summary !appendix From: Craig Carey Sent: Thursday, June 6, 2002 8:46 AM [1] Would it be an improvement, to allow the "entry_index_specification" (RM 9.5.2) (that can be used in protected objects) to be usable inside of tasks' select statements ?. Here is code showing how an entry_index_specification is, and is not available. protected body Objects_Manager is entry Onto_Free_List (for N in Requeuable_Etype) (Obj : Obj_type) when True is begin ... end Onto_Free_List; ... end body Objects_Manager; -- It can be used task body Fibre_Type (...) is procedure Do_Receive (N : Requeuable_Etype; ...) is ... end; ... begin <> select accept Receive (eFirst) (A : AT; B : out BT; C : out CT) do ... -- The data arrived so early that it can't be processed yet requeue IO_Receive (eSecond) with abort; end IO_Receive; ... end select; loop -- Loop 1 select accept Receive (eFirst) (A : AT; B : out BT; C : out CT) do Do_Receive (eFirst, A, B, C, D, E, F); end IO_Receive; or accept Receive (eRequeued) (A : AT; B : out BT; C : out CT) do Do_Receive (eRequeued, A, B, C, D, E, F); end Receive; or terminate; end select; end loop; ... goto RESTART; end Fibre_Type; It would seem to be an real improvement if the "(for N in Requeuable_Etype)" could done inside "accept"s statement too. Duplicating code in a way like is shown above can invite bugs, e.g. if the names of the parameters of the procedure (or the accept entry) are identical to the names of some of globals local to the task. Also "Receive'Caller" (which is used in examples of the "Adalog" task debugging software) can't be used inside of procedure "Do_Receive". It seems easy to put a (GNAT) Assert statement inside of a procedure but its effect might be unexpected. [2] Renamings of task type bodies inside of their bodies Also a nearby problem is that a new name for a task can't be created inside of its body. Such a renaming might create a longer name (e.g. if the task was "separate" and the name of the file had to be brief. **************************************************************** From: Randy Brukardt Sent: Friday, June 7, 2002 8:44 PM > Also "Receive'Caller" (which is used in examples of the "Adalog" task > debugging software) can't be used inside of procedure "Do_Receive". It > seems easy to put a (GNAT) Assert statement inside of a > procedure but its effect might be unexpected. This comment seems confused. It is necessary to specify which entry's accept's caller is being requested, as you could be in multiple rendezvous at one time. But there is no way to do that in an arbitrary piece of code, because it doesn't have access to the entry names (it does not know what task it was called from). So what is the prefix of the attribute?? In addition, it's possible that some implementations don't keep rendezvous data in a global data structure (as Janus/Ada does), but rather keeps it locally to the task (or even the accept statement). In that case, an external use of 'Caller would not know where to look for the information. If it is kept locally to the accept statement, it is possible that there are multiple copies (if there are multiple accepts as in your example), so even using the entry name from outside of the task would not provide enough information to find the needed data. (And using the entry name would require that the subprogram is only called from a single task, damaging reusability.) How do you propose to deal with these issues?? ****************************************************************