WebAssembly también bloquea el subproceso del trabajador web

Esto está relacionado con la pregunta anterior WebAssembly en código asíncrono

Básicamente, esa pregunta es sobre el problema de WebAssembly que bloquea el hilo principal, y la respuesta a la pregunta es mover el código de WebAssembly a un trabajador web. Eso funciona.

El problema ahora es que WebAssembly bloquea onmessage() en el trabajador.

Mi código WebAssembly de ejecución prolongada tiene funciones como play(), pause(), stop(), etc. Play() verifica periódicamente un indicador de pausa y un indicador de parada para determinar si play() debe regresar. La pausa () y la parada () se utilizan para establecer esas banderas.

El subproceso principal de JavaScript llama a postMessage() para enviar un mensaje al trabajador, que además llama a play().

Dado que onmessage() está bloqueado, el trabajador no tendrá posibilidad de recibir más mensajes para hacer pause() o stop() hasta que se complete play(). Eso anulará los propósitos mismos de la pausa/parada.

Parece que WebAssembly no admite el caso de uso simple de reproducir/pausar/detener.

¿Algún comentario o sugerencia?

Por cierto, ese caso de uso está bien respaldado por el desaparecido Google PNaCl.

Gracias.

Solución del problema

En resumen: los trabajadores web no ignoran los mensajes incluso si el subproceso del trabajador web está bloqueado.

Todos los eventos de los navegadores, incluidos los trabajadores postMessage()/ onmessage()eventos web, se ponen en cola. Esta es la filosofía fundamental de JavaScript ( onmessage()se hace en JS incluso si usa WebAssembly). Eche un vistazo a "Modelo de concurrencia y bucle de eventos" de MDN para obtener más detalles.

Entonces, lo que sucederá en su caso es que, mientras onmessage()está bloqueado, los eventos del hilo principal postMessage()se ponen en cola automáticamente. Cuando onmessage()finaliza un solo trabajo en el subproceso de trabajo, desde la cola de eventos del trabajador, verificará si postMessage()se llama antes de que finalice y captará el mensaje si lo hay. Por lo tanto, no necesita preocuparse por ese caso, siempre que el onmessage()trabajo tarde unos 10 segundos y obtenga cientos de eventos en la cola.

Así es como se realiza la ejecución asíncrona en todas partes del navegador.