[WASM] Chrome timer throttling affects runtime #51041
Description
Chrome recently turned on intensive timer throttling. The side-effect of this is that code that relied on timers firing at certain intervals may not work as expected. We first got reports of this issue with the SignalR Javascript library (dotnet/aspnetcore#31079), as it relies on client and server pings to detect connection closures. In addition, the SignalR .NET Client library has the same issue as it uses a timer to send the same pings.
The Javascript library was fixed by relying on
Intensive throttling is not applied to timers that are scheduled from a network response handler
-https://bugs.chromium.org/p/chromium/issues/detail?id=1186569#c3
The Javascript fix is at dotnet/aspnetcore#31300 for reference.
Unfortunately, the .NET client can not do the same thing because it uses .NET patterns (async await) which go through the wasm runtime. The wasm runtime very likely uses timers for scheduling work which will be chained and have throttling applied to them.
Specifically, I was noticing that when using a System.IO.Pipeline, calling FlushAsync on a Pipe and ReadAsync from another thread was taking more than 30 seconds for the ReadAsync to return after FlushAsync finished.
TLDR:
Wasm Runtime uses timers which will be throttled on Chrome, this can result in poor behavior for apps.
A potential change that could be made is to restart timers on network handlers so they aren't throttled.