Use a more reliable way to apply a timeout for a wasm function call with epoch interruption in the EpochInterruptionTests.
(This is not strictly required for this specific test as the wasm function is an infinite loop, but intended to be a better example illustrating this approach.)
When using a System.Threading.Timer with a dueTime, it could happen that the specified callback is called even after the timer was disposed, which could mean that if the wasm function isn't actually an infinite loop, the engine might already have been disposed when the timer callback is executed, which would lead to a crash due to an unhandled ObjectDisposedException thrown by Engine.IncrementEpoch().
In contrast, CancellationTokenRegistration.Dispose() waits until the callback is finished (if it's currently executing), so that it's guaranteed that after disposing the registration, Engine.IncrementEpoch() isn't called any more.
Use a more reliable way to apply a timeout for a wasm function call with epoch interruption in the
EpochInterruptionTests
.(This is not strictly required for this specific test as the wasm function is an infinite loop, but intended to be a better example illustrating this approach.)
When using a
System.Threading.Timer
with adueTime
, it could happen that the specified callback is called even after the timer was disposed, which could mean that if the wasm function isn't actually an infinite loop, the engine might already have been disposed when the timer callback is executed, which would lead to a crash due to an unhandledObjectDisposedException
thrown byEngine.IncrementEpoch()
.In contrast,
CancellationTokenRegistration.Dispose()
waits until the callback is finished (if it's currently executing), so that it's guaranteed that after disposing the registration,Engine.IncrementEpoch()
isn't called any more.