
event_after(+Event, +Time)

      Set up an event Event which is triggered after Time seconds have
   elapsed.



Arguments
   +Event              Atom
   +Time               Positive number

Type
   Event Handling

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 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.



Resatisfiable
      No.

Fail Conditions
      None.



Exceptions
     5 --- Event is not an atom 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_every / 2, cancel_after_event / 1, events_after / 1, event / 1, set_event_handler / 2, current_after_event / 1, get_flag / 2
