stt@ada-uts (05/31/88)
I have heard several complaints about the difficulty of delaying until a specific time, since the task may be preempted between the evaluation of the value of the clock (which can be expensive in its own right) and the execution of the delay. Any reaon not to include in Ada 9X a "DELAY_UNTIL statement" which takes a TIME rather than a DURATION? (One low-level reason is that TIME is not defined in package STANDARD, but then, neither is PRIORITY.) Most implementations of Delay reexpress the delay as an ending time anyway, thereby requiring yet another call on CLOCK. An alternative is to require that the delay statement "suspend further execution of the task that executes the delay statement, <including the time to evaluate the simple expression,> for at least the duration specified by the resulting value." This would then allow conforming implementations to recognize delay expressions of the form "delay x-calendar.clock" and optimize them internally to be "delay-until x." Alternatively, this would allow an implementation to implicitly read the clock before evaluating the simple expression, and then pass both the expression and the clock value as parameters to a run-time delay procedure. Probably the optimization mentioned above (replacing delay x-calendar.clock) with "delay-until x" is legal already since the evaluation of calendar.clock may be considered to take no time, and hence this might be a recommended approach for most real-time-oriented Ada compilers, thereby eliminating the danger of preemption as well as two calls on CLOCK. Tucker Taft Intermetrics, Inc. Cambridge, MA 02138