SIDE_MODULE and USE_PTHREADS provoke memory growth

[alexander-veselov]

I understand that "SIDE_MODULE + USE_PTHREADS" is experimental. But I would still like to know if this is a known issue and if it can be fixed somehow.

We have a lot of side modules (about 350MB). USE_PTHREADS=1 and PTHREAD_POOL_SIZE=20. With this configuration, an "out of memory" error occurs. It seems that all side modules are loaded several times for each thread.

For example, if you set PTHREAD_POOL_SIZE=1, then the problem will disappear.
I know that when building without side modules, the problem will also disappear, but we need side modules.

Is it possible to make threads use shared memory and not load copies of dynamic libs several times?

[kripken]

@sbc100 Is it the case that loading a dynamic library compiles on that pthread, so each pthread ends up recompiling the same code? (Unlike with the main module, which we compile once and just send that to the workers.)

I'm not sure how we could improve that. To send the compiled dynamic library we'd need to do an async postMessage. Perhaps with Asyncify or stack switching we could pause and wait for that.

[sbc100]

Thats good. The startup use-case should easier to handle. since in the cast the main thread can take care of postMessaging all the modules over to newly started threads because they actually start running.

For the dlopen case its tricky because the library should be loaded by any thread.. and dlopen is expected to by synchronous so we can't always return the even loop to process messages in the middle of it.

[alexander-veselov]

It would acceptable for us even if only main thread can use dlopen.

[sbc100]

The problem is that once the main thread calls dlopen there is a general expectation that the code can run on all threads. We have tried to our best to keep all threads in sync.. but its tricky. See

emscripten/system/lib/libc/dynlink.c

Lines 221 to 224 in b2dc6cf

	void _emscripten_thread_sync_code() {
	// This function is called from emscripten_yeild which itself is called
	// whenever we block on a futex. We need to check to avoid infinite
	// recursion when taking the lock below.

Would you would like to turn this discussion into a feature request, or open an new issue "Use postMessage to share side modules"? I'm not sure when I will get a chance to work on it but it might be something someone else want to a take a stab at.

[alexander-veselov]

I'm not sure. What's the difference? Well, let it be issue

[sbc100]

New issue: #17078