!(assertEqualToResult (catch (max-time! 1
(setup-call-cleanup! ((sleep! 2)
(change-state! &var 0))
((increment) (increment)) ;; don't call this
(increment))) ;; do call this
time_limit_exceeded
(time_limit_exceeded (get-state! &var)))
((time_limit_exceeded 1)))
But this fails, the only difference being the Setup form is wrapped in sequential:
!(assertEqualToResult (catch (max-time! 1
(setup-call-cleanup! (sequential ((sleep! 2)
(change-state! &var 0)))
((increment) (increment)) ;; don't call this
(increment))) ;; do call this
time_limit_exceeded
(time_limit_exceeded (get-state! &var)))
((time_limit_exceeded 1)))
The intent of using sequential is to ensure that we sleep strictly before we (change-state! &var 0), to verify the interrupt doesn't prevent Setup from completing in full. My understanding is that execution order wouldn't be guaranteed for the non-sequential form across other MeTTa implementations that do more with concurrency (though it might happen to be guaranteed with Mettalog atm).
The prolog documentation for
setup_call_cleanup/3
statesI think it is most sensible if our implementation reliably does the same. I believe the bug arises when multiple results are at play.
Setup:
Then this succeeds:
But this fails, the only difference being the Setup form is wrapped in sequential:
The intent of using sequential is to ensure that we sleep strictly before we
(change-state! &var 0)
, to verify the interrupt doesn't prevent Setup from completing in full. My understanding is that execution order wouldn't be guaranteed for the non-sequential form across other MeTTa implementations that do more with concurrency (though it might happen to be guaranteed with Mettalog atm).