Re: Missing accept statement

[arny@cbnewsl.ATT.COM (arny.b.engelson)]

In article <1990Mar15.203521.28171@planck.uucp> westley@hercules.uucp () writes:
[the following program runs flawlessly on Sun4 under Verdix]
>with Text_IO;
>procedure Missing_Task_Entry is
>   task A_Task is
>      entry Missing_Entry;
>   end A_Task;
>   task body A_Task is
>   begin -- A_Task
>      Text_IO.Put_Line ("A_Task");
>   end A_Task;
>begin -- Missing_Task_Entry
>   null;
>end Missing_Task_Entry;

>Is it valid for a task body to be lacking an accept statement for a
>corresponding entry from the specification of that task?  I can't find a
>specific rule in the RM, but this seems contrary to idea of the compiler
>catching this class of potential bugs.

>Terry J. Westley


I could not find anything in the ARM (or the commentaries) that says a task
MUST have an accept statement for every one of its declared entries, just
that there may be more than one.  At a minimum, the ARM should be clarified
on this point.  Assuming that this situation is therefore allowed, I would
hope a compiler would at least produce a warning message.  I would expect
any call to the entry to hang (unless it's a conditional/timed entry call).
In the above example, since there are no calls to the entry, the compiler may
have chosen not to bother with a warning message.  Try adding an entry call
and see if the compiler warns you about the impending deadlock.

The real question is "was it the intention of the language designers to
allow tasks to have zero accept statements for an entry?"  Well guys,
was it?  More questions: If so, why?  Is this really a good idea?

Enquiring minds want to know (and would love to see discussion on almost
anything that is not related to the Ada/C/C++/case/switch jihad).  :-)

  -- Arny Engelson   att!wayback!arny