¿Cómo funciona Task.Yield bajo el capó en el tiempo de ejecución de Mono/WASM (que utiliza Blazor WebAssembly)?
Para aclarar, creo que entiendo bien cómo funciona Task.Yield en .NET Framework y .NET Core. La implementación mono no se ve muy diferente, en pocas palabras, se reduce a esto:
static Task Yield() { var tcs = new TaskCompletionSource<bool>(); System.Threading.ThreadPool.QueueUserWorkItem(_ => tcs.TrySetResult(true)); return tcs.Task; }Sorprendentemente, esto también funciona en Blazor WebAssembly ( pruébelo en línea ):
<label>Tick Count: @tickCount</label><br> @code { int tickCount = System.Environment.TickCount; protected override void OnAfterRender(bool firstRender) { if (firstRender) CountAsync(); } static Task Yield() { var tcs = new TaskCompletionSource<bool>(); System.Threading.ThreadPool.QueueUserWorkItem(_ => tcs.TrySetResult(true)); return tcs.Task; } async void CountAsync() { for (var i = 0; i < 10000; i++) { await Yield(); tickCount = System.Environment.TickCount; StateHasChanged(); } } }Naturalmente, todo sucede en el mismo subproceso de bucle de eventos en el navegador, por lo que me pregunto cómo funciona en el nivel inferior.
Sospecho que podría estar utilizando algo como Asyncify de Emscripten , pero eventualmente, ¿utiliza algún tipo de API de plataforma web para programar una devolución de llamada de continuación? Y si es así, ¿cuál exactamente (comoqueueMicrotask , setTimout , Promise.resove().then , etc.)?
Actualizado , acabo de descubrir que Thread.Sleep también está implementado y en realidad bloquea el hilo del bucle de eventos 👀
También tengo curiosidad por saber cómo funciona eso en el nivel de WebAssembly. Con JavaScript, solo puedo pensar en un ciclo ocupado para simular Thread.Sleep (ya que Atomics.wait solo está disponible en subprocesos de trabajadores web).
Es setTimeout . Hay una considerable indirección entre eso y QueueUserWorkItem , pero aquí es donde toca fondo.
La mayoría de la maquinaria específica de WebAssembly se puede ver en PR 38029 . La implementación WebAssembly de RequestWorkerThread llama a un método privado denominado QueueCallback , que se implementa en código C como mono_wasm_queue_tp_cb . Esto invoca mono_threads_schedule_background_job , que a su vez llama a schedule_background_exec , que se implementa en TypeScript como:
export function schedule_background_exec(): void { ++pump_count; if (typeof globalThis.setTimeout === "function") { globalThis.setTimeout(pump_message, 0); } } La devolución de llamada setTimeout finalmente llega a ThreadPool.Callback , que invoca ThreadPoolWorkQueue.Dispatch .
El resto no es específico de Blazor en absoluto y se puede estudiar leyendo el código fuente de la clase ThreadPoolWorkQueue . En resumen, ThreadPool.QueueUserWorkItem pone en cola la devolución de llamada en un ThreadPoolQueue . Poner en cola llamadas a EnsureThreadRequested , que delega a RequestWorkerThread , implementado como se indicó anteriormente. ThreadPoolWorkQueue.Dispatch hace que una cantidad de tareas asincrónicas se eliminen y ejecuten; entre ellos, debería aparecer finalmente la devolución de llamada pasada a QueueUserWorkItem .