Diagrams to understand Emscripten's Pthread memory model

[badgermole]

Hi all!

I'm motivated to understand the memory model that results from using Emscripten's Pthread implementation. In particular, I find diagrams extremely helpful, so I've created the SVGs below using Inkscape.

I am currently working on a project where we are spinning up multiple dedicated workers to provide a service to handle file translation in batches where each worker/wasm instance statelessly handles a single file at a time. See diagram 1 below.
However, the C++ project itself handles concurrency, which I'm not taking advantage of. So I'm weighing the pros & cons of switching this implementation to one using Emscripten's Pthreads, and from reading, I've come so far to diagram 2 below.

As an aside, I'm concerned about memory growth. At this point, I am terminating workers that have processed N files as I'm finding that memory usage is getting out of hand.

In the Pthreads scenario, my understanding is that Emscripten is using regular dedicated web workers. So does the memory context for those workers reside as part of the memory of the wasm module that invokes the workers(parent), or does that memory reside separately outside of the parent worker? And what about the SharedArrayBuffer between the parent and its child thread?

I'm trying to make decisions on getting the right balance between speed and memory usage.

Is my understanding correct? I would love to have some accurate diagrams.

Thanks :o)
__

Diagram 1:

Diagram 2:

[sbc100]

I think you are mostly on the right track here. Regarding the wasm module, the module itself is shared between the workers but each worker instantiates it separately.

All of the memory lives in a single SAB which is shared between them main thread an all the workers. The stack space for each thread along with the shared heap is all part of this single SAB.

[badgermole]

... Regarding the wasm module, the module itself is shared between the workers but each worker instantiates it separately.

You are referencing diagram 1, correct? - which is what I'm doing currently. But I'm thinking of replacing that with the single worker having the single instantiation of the wasm module, which itself creates a sub-worker for each pthread.

All of the memory lives in a single SAB which is shared between them main thread an all the workers. The stack space for each thread along with the shared heap is all part of this single SAB.

Does this modification of diagram 2 capture your correction, or how should I draw this differently?

[sbc100]

I just landed a change which completely removes the .worker.js by the way: #21701. Hopefully that might simplify that diagram since how there is just a single main JS file which is loaded both on the main thread and on the pthread workers.

I'm not sure what Interior Wall and Exterior Wll mean in this diagram but the pthread mostly makes sense to me.

[badgermole]

@sbc100, #21701 sounds great! And I think will save us from some headaches. It doesn't change the diagram, but that just tells me that I didn't have enough detail. I think that instead of "Worker - JS" in the outer bubble, if I said, "Worker - my.js" to go with the "C++ my.wasm" in the interior bubble, that may be it? And with #21701, I won't need to mess with a second .worker.js file.

Regarding the 'Walls' - those are my euphemisms denoting where we need to think about data transfer. The Interior Wall involves any transfer between C++ and the encapsulating worker JS. The Exterior Wall involves any transfer between the worker and the main thread/loop.