Thanks Kish, that will do fine. Here is the way to do it in order to have different behaviors according to whether the Goal succeeded, failed or was interrupted: start:- block(run_goal(Goal), too_long, goal_stopped), continue, ... run_goal(Goal):- event_after(too_long, 100), once(((Goal, goal_succeeded) ; goal_failed)), cancel_after_event(too_long). and define the predicates goal_stopped, goal_succeeded and goal_failed accordingly. In any case the execution will continue normally after the block command (except in the case goal_stopped fails. Loizos At 05:40 μμ 2/11/2001 +0000, Kish Shen wrote: > >>I need some help on the following issue. I have a piece of code like: > >>start:- >> set_event_handler(too_long, stop_execution/0), >> event_after(too_long, 100), >> compute, >> cancel_after_event(too_long). > >I assume you defined stop_execution/0 to fail, and this did not cause >compute/0 to fail? The manual probably should be clearer, but any failures >inside the after event handler goal is not propagated. This allows all >pending after events to be handled. > >In order to cause a failure in the `outer' computation, the handler should >not fail directly, but set up and trigger another goal that is executed >which does cause the failure. The simplest way to do this is to wrap your >compute/0 in a block/3: > > start :- > set_event_handler(too_long, exit_block/1), > event_after(too_long, 100), > block(compute, too_long, fail), > cancel_after_event(too_long). > >Note that if compute/0 fails on its own, the after event is not turned >off. For a more elaborate example, take a look at the timeout/4 example at >the end of the Events and Interrupts chapter of the User Manual. > >Cheers, > >Kish Shen > _________________________________________ Loizos Michael (gemichael@cytanet.com.cy)Received on Sat Nov 03 12:47:53 2001
This archive was generated by hypermail 2.1.8 : Wed 16 Nov 2005 06:07:11 PM GMT GMT