[ Event Handling | The ECLiPSe Built-In Predicates | Reference Manual | Alphabetic Index ]

event_after(+Event, +Time)

Set up an event Event which is triggered after Time seconds have elapsed.
+Event
Atom or Handle
+Time
Positive number

Description

The event Event is raised after Time seconds of elapsed time from when the predicate is executed. The same Event can be raised multiple times at different intervals with multiple calls to event_after/2, event_after/3 and event_after_every/2. Note that elapsed time is not necessarily elapsed real time (see later).

Time can be a real number, but the actual granularity of how fine the elapsed time is measured is operating system dependent, and the triggering condition is actually that at least Time seconds have elapsed.

In addition, the processing of an event may not happen immediately upon the raising the event, as events are processed synchronously: An event can only be handled at a point where an ECLiPSe goal can be executed. This can delay the handling of an event when ECLiPSe is performing some uninterruptible task, e.g. waiting for I/O, or executing external code.

Moreover (unlike event handling in general) the handling of after-events is serialised. This means that after-event handlers do not interrupt each other. When one after-event becomes due while another after-event handler is still executing, the new one will wait until the executing one has finished.

After-event handlers are also executed at priority 1, which means that no woken goals will execute while inside such a handler.

After-event handlers should not fail, and the system will actually ignore the failure of a handler.

After-event handlers may abort with exit_block/1 (throw/1), but the programmer has to be aware that, due to the timed execution, the exact program point where the abort happens is unpredictable. It must be made sure that the abort is safely caught in all cases, and that nonlogical data is not left in an inconsistent state. Also, an abort may prevent further after-events (which have already become due) from being handled.

The timer used by measuring elapsed time is specified by the environment flag after_event_timer: virtual means that elapsed user cpu time is used, real means elapsed real time. The default is real. On systems that cannot support CPU time measurement, such as Microsoft Windows, one may not set the timer to virtual: an error is raised if this is attempted.

Fail Conditions

None.

Resatisfiable

No.

Exceptions

(5) type error
Event is neither an atom nor a handle or Time is not a positive number.

Examples

   setup :-
      set_event_handler(hi, hi/0),
      % set up event `hi' to occur once 3.2 seconds later
      % and the hi event will trigger the execution of hi/0.
      event_after(hi, 3.2).

   hi :-
      writeln(hi).

See Also

event_after / 3, event_after_every / 2, cancel_after_event / 2, events_after / 1, event / 1, set_event_handler / 2, current_after_events / 1, event_create / 2, event_retrieve / 2, get_flag / 2