Question About pthread Message Handling in Web Workers

[Александр Гурьянов]

Hi there,

I recently launched my first project using pthread in the browser, and I'm now trying to better understand how it actually works under the hood.

One thing I’m particularly curious about is how pthread handles messages from the main thread or other workers. For example, if a pthread-created thread runs a loop like this:

while (true) {
   // perform some logic
   // process events
   // respond
   sleep(5);
}

From what I understand, this setup shouldn't work without asyncify, since the infinite loop would block the worker and prevent it from handling incoming messages. However, I’ve seen this kind of pattern in a game project, and it seems to work just fine. Am I missing something?

Is it possible to run an infinite loop inside a worker and still receive messages from other threads?

My guess is that this might work using SharedArrayBuffer, since it's always in sync and doesn’t rely on the worker’s message queue. But is it considered normal for a worker to be in an infinite loop and never respond to messages?

Last thing, can pthread-woreker use asyncify?

I’d really appreciate any insights on this!

Thanks a lot, Alex

[Sam Clegg]

The short answer is that, yes, in most cases its fine for pthread workers to block forever and never return the event loop.

All the core communication with threads happens through shared memory so there should be no postMessages happening once a thread is up and running.

If a pthread does what to yield to event loop it can do so, but it will need to mark itself as alive so that it doesn't exit.  This happens automatically for async functions but you can also use `emscripten_runtime_keepslive_push` to `emscripten_exit_with_live_runtime`, both of which will make the current thread as wanted to stay alive once it returns to the event loop.

Finally, yes, it should be fine to use asyncify within pthreads, although its much less useful there since blocking the event loop is not generally an issue like it is on the main thread.

cheers,

sam

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVEkCNX0NyHfgzy7c%2BG84or9ocySG%2BfcZ-Tasz3fZt42xA%40mail.gmail.com.

[Александр Гурьянов]

Nice — just to clarify, as far as I understand, this pattern won't work with the FS code, right? Since the FS is stored in the main, and by default it relies on message passing, that wouldn't function properly in a forever loop context?

чт, 3 апр. 2025 г. в 02:32, 'Sam Clegg' via emscripten-discuss <emscripte...@googlegroups.com>:

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va28ChuFZbxGH-vB8JGdyCKt%3DzAFqXw2TAGrMYsmp9C2YRQ%40mail.gmail.com.

[Sam Clegg]

In the old filesystem all FS calls are proxied back to the main thread and run there.  The proxying mechanism does not depend on postMessage, only shared memory.

In the new WasmFS filesystem there are some cases where FS operations operate purely on shared memory and don't require proxying (i.e. memfs) and others that do require proxying, but again, no postMessage is required in any of these cases.

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAKOm%3DVFpepTvDcB4ZQAU9mTVpdtiV%2BGz7_E-tFYAs3fHJeKLLg%40mail.gmail.com.